Project

General

Profile

Bug #7482

NFSv4 rename of open file fails when nbmand=on

Added by Gordon Ross about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2016-10-18
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

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/nfs

On 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.
  1. cd /mnt/nfs
  2. 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

Expected Results:
This rename should be allowed, so long as no clients have a "deny delete" share reservation.

Actual Results:
A solitary client can't rename files when nbmand is enabled.

#1

Updated by Gordon Ross about 4 years ago

  • Status changed from New to In Progress
#2

Updated by Electric Monk about 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 3d4d3e7cf922f4234d4e564d9639b1f203561cf6

commit  3d4d3e7cf922f4234d4e564d9639b1f203561cf6
Author: Gordon Ross <gwr@nexenta.com>
Date:   2016-10-28T18:16:10.000Z

    7482 NFSv4 rename of open file fails when nbmand=on
    Reviewed by: Evan Layton <evan.layton@nexenta.com>
    Reviewed by: Matt Barden <matt.barden@nexenta.com>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Approved by: Matthew Ahrens <mahrens@delphix.com>

Also available in: Atom PDF