NFSv4 rename of open file fails when nbmand=on
When enabling nbmand on a filesystem shared out by NFSv4, NFS 'RENAME' operations become inoperable: the RENAME returns a NFS4ERR_FILE_OPEN to the RENAME.
This happens even when only one client (the NFSv4 client) is attempting the rename, and there are no "deny delete" share reservations.
Steps to Reproduce:
Export a share:
zfs set sharenfs=on mypool/test
Mount that share on a client. This has been tested on SuSE Leap 43, CentOS 7, Ubuntu 16.04. # mount -t nfs4 nex404:/mypool/test /mnt/nfsOn the client, use a visual editor which uses a temporary scratch file, in this case, gedit was used. The client reports they can reproduce this with several editors.
- cd /mnt/nfs
- gedit file
Write something into the file. Save it. Add some more data to the file. Save it again: the client application errors, providing us with the NFS4ERR_FILE_OPEN error.
In a snoop trace, we do not see NFS4ERR_FILE_OPEN as a response
This rename should be allowed, so long as no clients have a "deny delete" share reservation.
A solitary client can't rename files when nbmand is enabled.
Updated by Electric Monk about 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 3d4d3e7cf922f4234d4e564d9639b1f203561cf6 Author: Gordon Ross <email@example.com> Date: 2016-10-28T18:16:10.000Z 7482 NFSv4 rename of open file fails when nbmand=on Reviewed by: Evan Layton <firstname.lastname@example.org> Reviewed by: Matt Barden <email@example.com> Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Approved by: Matthew Ahrens <email@example.com>