Quoting Joseph Tam jtam.home@gmail.com:
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/
The dovecot user, as in the "dummy" user dovecot uses for sandboxing, or the UID of the user logged in via IMAP through dovecot?
No, the (dovecot user) doesn't have access to the director(ies), but the logged-in users DO. That's no different from the mail directories in /home/*, though, which are 0700/owned-by-their-respective-users.
I have confirmed by using "su -" to the various UIDs that they can fully access the mailboxes behind the symlinked directories.
I'm thinking no .subscription would be better.
Done, but it makes no difference.
Dovecot does have chroot-ing stuff that might impede symlink following:
I'm not running dovecot chrooted. That's a bear of a very different species, and one I'd not care to wrestle for this sort of setup. Maybe in a "vpopmail" type of situation where dovecot only runs as a delegate UID where there are no real system UIDs/GIDs for the users in question.
There's no dovecotian "AllowSymlink" analogue to Apache's FollowSymLinks directive, I assume? I scoured through the documentation, but didn't see anything, but it's not the first time I've missed things in documentation.
It seems you have more basic file access problems.
I suspect so, but it's a strange one, because (al)pine and UW-imapd have accessed these mailboxes without any issues for many years, as much as it comes as a shock that such decrepit software could ever be accused of performing correctly.
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/testbox
Will do. My thanks, Joseph.
=M=