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,
smime.p7s
Description: S/MIME Cryptographic Signature
