I think I found the reason of this issue:
The unfsd service manual tells in the nfs3 bug section that all the path needs to be in exec rights for the user, and that the server executes the requests with the same uid, gid as the client (except for root if not autorised - which is not my case).
http://linux.die.net/man/8/unfsd
My client running Nginx is running in root for the master and in applicative user for the workers. The getattr requests sent to the nfs server when the file is not cached are done in applicative user (sent by the workers apparently) and the write requests are done by the master (in root).
As I had the wrong owner on one of my folders the NFS server refused my getattr request. When the file is already opened in root by another application such as tail -f, the client has no need to send this request.
Conclusion: Just verify the rights and owner of all the folders on the server!
Hope this might be useful if some of you gets the same problem :)
The unfsd service manual tells in the nfs3 bug section that all the path needs to be in exec rights for the user, and that the server executes the requests with the same uid, gid as the client (except for root if not autorised - which is not my case).
http://linux.die.net/man/8/unfsd
My client running Nginx is running in root for the master and in applicative user for the workers. The getattr requests sent to the nfs server when the file is not cached are done in applicative user (sent by the workers apparently) and the write requests are done by the master (in root).
As I had the wrong owner on one of my folders the NFS server refused my getattr request. When the file is already opened in root by another application such as tail -f, the client has no need to send this request.
Conclusion: Just verify the rights and owner of all the folders on the server!
Hope this might be useful if some of you gets the same problem :)