Dovecot permission denied errors on NFS after upgrade to 2.2.17

[Mark Moseley]

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>