Re: Dovecot permission denied errors on NFS after upgrade to 2.2.17
Thanks Jochen,
no mixups present at all, file assigned to UID 501.
Since this problem started few hours after the Debian upgrade, I think it is related to it.
I don't know if something has changed on the NFS client side on Debian, but I don't think so as aptlistchanges didn't notify me about it, nor if Dovecot 2.2.17 treat NFS in other way.
I'm stuck.
On 13/07/20 16:07, Jochen Bern wrote:
On 07/13/2020 03:45 PM, Claudio Corvino wrote:
in addition the "permission denied" error is random, most of the time Dovecot works well. In *that* case, I'd say that UID/GID mapping problems can be ruled out.
How can I check the mappings NFS uses? You don't have any relevant options in the client's fstab entry, and I'll assume that there are none in the server's /etc/exports, either. That leaves only potential default mappings, which should be documented in the corresponding manpages.
Also, since there's only *one* user/group involved, you can always "chown" a test file on one side and check with "ls -n" on the other to verify whether there are mixups.
*Intermittent* failures of an NFS mount over a well-functioning LAN ... I'm thinking "file locking" now, but that's a *complicated* topic, to say the least ...
https://en.wikipedia.org/wiki/File_locking#Problems https://unix.stackexchange.com/questions/553645/how-to-install-nfslock-daemo...
Regards,
On Mon, Jul 13, 2020 at 7:36 AM Claudio Corvino ccorvino@trustitalia.it wrote:
Thanks Jochen,
no mixups present at all, file assigned to UID 501.
Since this problem started few hours after the Debian upgrade, I think it is related to it.
I don't know if something has changed on the NFS client side on Debian, but I don't think so as aptlistchanges didn't notify me about it, nor if Dovecot 2.2.17 treat NFS in other way.
I'm stuck.
On 13/07/20 16:07, Jochen Bern wrote:
On 07/13/2020 03:45 PM, Claudio Corvino wrote:
in addition the "permission denied" error is random, most of the time Dovecot works well. In *that* case, I'd say that UID/GID mapping problems can be ruled out.
How can I check the mappings NFS uses? You don't have any relevant options in the client's fstab entry, and I'll assume that there are none in the server's /etc/exports, either. That leaves only potential default mappings, which should be documented in the corresponding manpages.
Also, since there's only *one* user/group involved, you can always "chown" a test file on one side and check with "ls -n" on the other to verify whether there are mixups.
*Intermittent* failures of an NFS mount over a well-functioning LAN ... I'm thinking "file locking" now, but that's a *complicated* topic, to say the least ...
https://unix.stackexchange.com/questions/553645/how-to-install-nfslock-daemo...
Regards,
This is just me throwing things out to look at, but did the client mount on the old server use NFS3 and the new upgraded client uses NFS4? Sometimes that can cause weirdness with id mapping.
"Mark" == Mark Moseley moseleymark@gmail.com writes:
Mark> This is just me throwing things out to look at, but did the Mark> client mount on the old server use NFS3 and the new upgraded Mark> client uses NFS4? Sometimes that can cause weirdness with id Mark> mapping.
Another thing to check is selinux, is it enabled? It's one of those things I have to poke at on RHEL systems, but I can't remember if it's on by default on Debian Buster.
getenforce
would answer one way or another. John
Strange behavior but after a reboot of the Dovecot server, the error disappeared from logs (like Windows style! :-)).
I'll monitor the situation and take you updated in case it should come back.
Thanks all!
On 13/07/20 20:27, John Stoffel wrote:
"Mark" == Mark Moseley moseleymark@gmail.com writes:
Mark> This is just me throwing things out to look at, but did the Mark> client mount on the old server use NFS3 and the new upgraded Mark> client uses NFS4? Sometimes that can cause weirdness with id Mark> mapping.
Another thing to check is selinux, is it enabled? It's one of those things I have to poke at on RHEL systems, but I can't remember if it's on by default on Debian Buster.
getenforcewould answer one way or another. John
Hi everyone,
after some hours when I sent my last e-mail to the ML the problem reoccurred, again problem with some mailboxes reading some e-mails and many errors into dovecot.log like these:
/Jul 14 15:07:50 imap(XXX): Error: open(/mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m) failed: Permission denied (euid=501(vmail) egid=501(vmail) missing +r perm: /mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m stat(/mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m) failed: Permission denied)/
SElinux is not installed and Dovecot NFS client uses "defaults" option to mount NFS partition with mailboxes in it and version=3.
Don't know where to look further.
Any help appreciated!
Regards
On 14/07/20 11:13, Claudio Corvino wrote:
Strange behavior but after a reboot of the Dovecot server, the error disappeared from logs (like Windows style! :-)).
I'll monitor the situation and take you updated in case it should come back.
Thanks all!
On 13/07/20 20:27, John Stoffel wrote:
> "Mark" == Mark Moseley moseleymark@gmail.com writes:
Mark> This is just me throwing things out to look at, but did the Mark> client mount on the old server use NFS3 and the new upgraded Mark> client uses NFS4? Sometimes that can cause weirdness with id Mark> mapping.
Another thing to check is selinux, is it enabled? It's one of those things I have to poke at on RHEL systems, but I can't remember if it's on by default on Debian Buster.
getenforce
would answer one way or another. John
Hi everyone,
problem still occurring, I just noticed that if I do an "ls -l /mnt/mail-storage/<user>/Maildir/cur/" from the Dovecot server I can unblock the mailbox of the user and Thunderbird can receives all the e-mails.
The problem occurs even with the gmail client on the smartphone.
I just tried many things but can't find a solution.
I just reinstalled a new server with mail storage not on NFS and the problem seems to be fixed, but this is not a solution valid for us as we would like to use NFS.
Thanks
On 20/07/20 09:47, Claudio Corvino wrote:
Hi everyone,
after some hours when I sent my last e-mail to the ML the problem reoccurred, again problem with some mailboxes reading some e-mails and many errors into dovecot.log like these:
/Jul 14 15:07:50 imap(XXX): Error: open(/mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m) failed: Permission denied (euid=501(vmail) egid=501(vmail) missing +r perm: /mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m stat(/mnt/mail-storage/XXX/Maildir/cur/1594641298.M607225P10899.XXX,S=4465,W=4534:2,m) failed: Permission denied)/
SElinux is not installed and Dovecot NFS client uses "defaults" option to mount NFS partition with mailboxes in it and version=3.
Don't know where to look further.
Any help appreciated!
Regards
On 14/07/20 11:13, Claudio Corvino wrote:
Strange behavior but after a reboot of the Dovecot server, the error disappeared from logs (like Windows style! :-)).
I'll monitor the situation and take you updated in case it should come back.
Thanks all!
On 13/07/20 20:27, John Stoffel wrote:
>> "Mark" == Mark Moseley moseleymark@gmail.com writes:
Mark> This is just me throwing things out to look at, but did the Mark> client mount on the old server use NFS3 and the new upgraded Mark> client uses NFS4? Sometimes that can cause weirdness with id Mark> mapping.
Another thing to check is selinux, is it enabled? It's one of those things I have to poke at on RHEL systems, but I can't remember if it's on by default on Debian Buster.
getenforce
would answer one way or another. John
On 21 Sep 2020, at 01:48, Claudio Corvino ccorvino@trustitalia.it wrote:
problem still occurring, I just noticed that if I do an "ls -l /mnt/mail-storage/<user>/Maildir/cur/" from the Dovecot server I can unblock the mailbox of the user and Thunderbird can receives all the e-mails.
The problem occurs even with the gmail client on the smartphone.
I just tried many things but can't find a solution.
I just reinstalled a new server with mail storage not on NFS and the problem seems to be fixed, but this is not a solution valid for us as we would like to use NFS.
This spends like it may be your system not really mounting (or not fully mounting) the NFS until it is actually accessed directly.
-- I DID NOT SEE ELVIS Bart chalkboard Ep. 7G07
Hi,
this sound correct, here is my fstab entry:
/XXX.XXX.XXX.XXX:/mail-storage /mnt/mail-storage nfs defaults,timeo=30 0 0/
Here are my options when doing "mount":
/rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=30,retrans=2,sec=sys,mountaddr=//XXX.XXX.XXX.XXX//,mountvers=3,mountport=50141,mountproto=udp,local_lock=none,addr=//XXX.XXX.XXX.XXX/
How can I do further test?
Thanks in advance
Claudio
On 23/09/20 22:26, @lbutlr wrote:
On 21 Sep 2020, at 01:48, Claudio Corvino ccorvino@trustitalia.it wrote:
problem still occurring, I just noticed that if I do an "ls -l /mnt/mail-storage/<user>/Maildir/cur/" from the Dovecot server I can unblock the mailbox of the user and Thunderbird can receives all the e-mails.
The problem occurs even with the gmail client on the smartphone.
I just tried many things but can't find a solution.
I just reinstalled a new server with mail storage not on NFS and the problem seems to be fixed, but this is not a solution valid for us as we would like to use NFS. This spends like it may be your system not really mounting (or not fully mounting) the NFS until it is actually accessed directly.
It seems that upgrading kernel from 4.9.0 to 4.19.0 fixed the problem.
Thanks for your help
On 24/09/20 14:31, Claudio Corvino wrote:
Hi,
this sound correct, here is my fstab entry:
/XXX.XXX.XXX.XXX:/mail-storage /mnt/mail-storage nfs defaults,timeo=30 0 0/
Here are my options when doing "mount":
/rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=30,retrans=2,sec=sys,mountaddr=//XXX.XXX.XXX.XXX//,mountvers=3,mountport=50141,mountproto=udp,local_lock=none,addr=//XXX.XXX.XXX.XXX/
How can I do further test?
Thanks in advance
Claudio
On 23/09/20 22:26, @lbutlr wrote:
On 21 Sep 2020, at 01:48, Claudio Corvinoccorvino@trustitalia.it wrote:
problem still occurring, I just noticed that if I do an "ls -l /mnt/mail-storage/<user>/Maildir/cur/" from the Dovecot server I can unblock the mailbox of the user and Thunderbird can receives all the e-mails.
The problem occurs even with the gmail client on the smartphone.
I just tried many things but can't find a solution.
I just reinstalled a new server with mail storage not on NFS and the problem seems to be fixed, but this is not a solution valid for us as we would like to use NFS. This spends like it may be your system not really mounting (or not fully mounting) the NFS until it is actually accessed directly.
participants (4)
-
＠lbutlr
-
Claudio Corvino
-
John Stoffel
-
Mark Moseley