On 14-12-2024 14:23, dovecot--- via dovecot wrote:
So the debugging confirms I am authenticated properly and looks to be opening the folder I expected: Dec 14 12:10:32 Backup dovecot[1139994]: pop3(peter)<1144790><>: Debug: fs: root=/home/peter/mail, index=, indexpvt=, control=, inbox=/var/spool/mail/peter, alt= Dec 14 12:10:32 Backup dovecot[1139994]: pop3(peter)<1144790><>: Debug: Mailbox INBOX: Mailbox opened because: POP3 INBOX Dec 14 12:10:32 Backup dovecot[1139994]: pop3(peter)<1144790><>: Error: Mailbox INBOX: stat(/var/spool/mail/peter) failed: Permission denied
I had a thought, as user peter, even though I own /var/spool/mail/peter I am unable to access it: [peter@Backup ~]$ ls /var/spool/mail/peter ls: cannot access '/var/spool/mail/peter': Permission denied
The inability of peter to access that directory is presumably the root cause. So, what is best practice:
- Use a folder in /home/peter/mail instead
- Enable correct access to /var/spool/mail/peter (so that user peter can access it)
My desire is to get system generated mail (currently delivered to the file /var/spool/mail/root) to be picked up from another machine by user peter (I would have used user root but I have also discovered that root seems to be blocked from remote e-mail access - I will have to work out how to get system processes to deliver status e-mails to a different user but that is a different problem once I can successfully pickup mail).
Hi,
Is there any reason that you are using system users? Does a console user with account 'peter' actually need to have access to the mail on the machine running dovecot?
In general, I find a setup using virtual users a lot easier to manage: no filesystem problems like the one you have, as all mail is handled using a single uid/gid (named vmail/vmail or so).
See https://doc.dovecot.org/2.3/configuration_manual/virtual_users/ for differences and details.
Kind regards,
tom