Error: Couldn't open INBOX: Permission denied
I'm trying to get Dovecot working on Rocky 9.5.
In 10-mail.conf I have: mail_privileged_group = mail mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u
In /var/spool: drwxr-x---. 3 mail mail 64 Dec 13 16:29 mail
In /var/spool/mail: -rw-rw----. 1 peter mail 500 Dec 13 16:29 peter
When I try to login using Telnet I get the following in /var/log/maillog: Dec 13 17:03:23 Backup dovecot[690594]: pop3-login: Login: user=<peter>, method=PLAIN, rip=172.21.10.5, lip=172.21.10.5, mpid=690664, secured, session=<8Or5zikp7uCsFQoF> Dec 13 17:03:23 Backup dovecot[690594]: pop3(peter)<690664><>: Error: Couldn't open INBOX: Permission denied Dec 13 17:03:23 Backup dovecot[690594]: pop3(peter)<690664><>: Disconnected: Couldn't open INBOX: Permission denied top=0/0, retr=0/0, del=0/0, size=0
(There is a random data between <> - I've deleted it as I'm not sure if it is sensitive.
I'm certain I'm typing the password correctly in Telnet and I think the first of the three lines from the log indicate that I successfully connected. But why do I get Permission denied when Dovecot tries to open the INBOX? As far as I can see I've set them right (as per the permissions pasted above).
Am 13.12.24 um 19:11 schrieb dovecot--- via dovecot:
mail_location = mbox:~mail:INBOX=/var/spool/mail%u / missing between mail and %u
Also %n may be more useful as %u _usually_ is user@domain.tld (possibly not in your configuration, cannot check, your config excerpt is too limited)
The / is not missing (not sure how it's disappeared for you as I can actually see it in my original post - I thought I'd somehow accidentally deleted it). %n didn't make any difference. My reason for wanting to get this going is not to deliver e-mail over the internet but to use it to monitor internally system messages on the server. Is there anywhere that I can get more logs - when it says Permission denied it would be helpful to know what it was trying to open as that might give me a clue as to what I've got wrong in my config.
Am 14.12.24 um 08:34 schrieb dovecot--- via dovecot:
The / is not missing (not sure how it's disappeared for you as I can actually see it in my original post - I thought I'd somehow accidentally deleted it).
It seems to be eaten by my MUA trying to interpret /italics/ in text only email. Sorry for the confusion!
My reason for wanting to get this going is not to deliver e-mail over the internet but to use it to monitor internally system messages on the server. Is there anywhere that I can get more logs - when it says Permission denied it would be helpful to know what it was trying to open as that might give me a clue as to what I've got wrong in my config.
You can set mail_debug=yes cf. https://doc.dovecot.org/2.3/admin_manual/debugging/mail_debugging/
Running doveadm -D force-resync -u peter INBOX may also provide you useful hints on what it does not find / cannot access. It should tell you something about uid, gid and the home directory path active for the user. It may not be matching what you expected / try to configure.
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).
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
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
So that means you should deliver/redirect this email to peter (or you need to start messing with shared/public mailboxes)
Is there any reason that you are using system users?
Linux authorisation/authentication is the best, you don't want to rely on crappy virtual user implementation of some developer who's core business is not even auth.
Does a console user with account 'peter' actually need to have access to the mail on the machine running dovecot?
Where does he write a system user is a console user?
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).
What he does here is good. Not wanting to do filesystem permissions because you can't set them up correctly is not really the way to go. Security is always based om multiple layers
In general, I find a setup using virtual users a lot easier to manage:
I thought it looked harder to setup virtual users (I had read about them). I have found that the trivial answer has been to change the permissions on /var/spool/mail directory (only mail user and group had access - my user needs at least read access to the folder).
Hi,
On 14.12.24 14:23, dovecot--- via dovecot wrote:
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)
it depends. ;-)
If you select option 2:
You wrote:
In /var/spool: drwxr-x---. 3 mail mail 64 Dec 13 16:29 mail
Please try this as root:
chmod 755 /var/mail
so the permissions will now look like this:
drwxr-xr-x. 3 mail mail 64 Dec 13 16:29 mail
And now user 'peter' should have access to it's mail file '/var/spool/mail/peter'.
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).
The classic way to do this is to change '/etc/aliases' and add this entry:
root: peter
or something like this, if you want to have the mail in both mailboxes 'root' _and_ 'peter':
root: \root, peter
Run 'newaliases' after that change.
HTH and regards, Markus
participants (5)
-
Daniel Lange
-
dovecot＠crighton.me.uk
-
Marc
-
Markus Winkler
-
Tom Hendrikx