I've tried changing how I symbolically linked the mailboxes, i.e., creating a sub-directory that is symlinked into the user's mail/ directory versus symbolically linking the mbox files themselves, etc. No dice. Permissions are fine. I've even resorted to changing the index locking strategy, to no avail.
I've tested my setup by symlinking both folders and boxes with user/0700 permissions, and they all work fine.
Folders that are NOT symbolically linked work perfectly, and have various levels of hierarchy that are selectable as expected. Nothing appears in the logs.
$ cd ~/mail $ ls -l -rw------- 1 2411625 Dec 16 09:12 Dovecot lrwxrwxrwx 1 21 Jun 13 18:01 OldMail -> /u2/usermail/luser -rwx------ 8 4096 Jan 1 12:09 "Open Source Projects"
If this is output on the dovecot server itself so there's no mismatch in pathnames. Have you checked whether the dovecot user can traverse all the way from / to /u2/usermail/luser/
I've (rm ~/mail/.subscriptions && touch ~/mail/.subscriptions) to flush any subscriptions file issues.
I'm thinking no .subscription would be better.
Is there a subtle interaction with mail_full_filesystem_access settings, or similar that might be getting in the way?
Dovecot does have chroot-ing stuff that might impede symlink following:
https://wiki.dovecot.org/ChrootingOther data: there are fs quotas on / but not /u2. That shouldn't matter, but I will concede that I'm not a little ignorant about such things.
It seems you have more basic file access problems.
How might I go about further debugging this? I've tried to manually doveadm index those mailboxes, which doesn't give me any errors, but it also returns far too quickly to give me the impression that it's done anything. Same result.
Nothing with verbose logging (set mail_debug = yes)? Try the simple case
ln -s /u2/usermail/luser/OLD_INBOX/INBOX_2016_01_to_08 ~luser/mail/testboxthen
$ telnet localhost 10143
x0 login luser ***
x1 SELECT testboxWhat do you get here and in your logs?
If this doesn't produce any usable diagnostics, I would pull out the heavy duty process trace tool and trace the imap process to figure out what it's really doing and where it's failing.
Joseph Tam jtam.home@gmail.com