Claudio Corvino
2020-Jul-13 14:36 UTC
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-daemon > > Regards,-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3812 bytes Desc: S/MIME Cryptographic Signature URL: <https://dovecot.org/pipermail/dovecot/attachments/20200713/eaa1fa59/attachment.p7s>
Mark Moseley
2020-Jul-13 17:54 UTC
Dovecot permission denied errors on NFS after upgrade to 2.2.17
On Mon, Jul 13, 2020 at 7:36 AM Claudio Corvino <ccorvino at 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://en.wikipedia.org/wiki/File_locking#Problems > > > https://unix.stackexchange.com/questions/553645/how-to-install-nfslock-daemon > > > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20200713/7155aed2/attachment-0001.html>
John Stoffel
2020-Jul-13 18:27 UTC
Dovecot permission denied errors on NFS after upgrade to 2.2.17
>>>>> "Mark" == Mark Moseley <moseleymark at 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
Reasonably Related Threads
- Dovecot permission denied errors on NFS after upgrade to 2.2.17
- Dovecot permission denied errors on NFS after upgrade to 2.2.17
- Dovecot permission denied errors on NFS after upgrade to 2.2.17
- Dovecot permission denied errors on NFS after upgrade to 2.2.17
- Duplicate e-mail with Dovecot and Sieve