On 3/21/25 10:36 AM, Benjamin Coddington wrote: > On 20 Mar 2025, at 13:53, Chuck Lever wrote: > >> On 3/19/25 5:46 PM, NeilBrown wrote: >>> On Thu, 20 Mar 2025, Dai Ngo wrote: >>>> Hi, >>>> >>>> Currently when the local file system needs to be unmounted for maintenance >>>> the admin needs to make sure all the NFS clients have stopped using any files >>>> on the NFS shares before the umount(8) can succeed. >>> >>> This is easily achieved with >>> echo /path/to/filesystem > /proc/fs/nfsd/unlock_filesystem >>> >>> Do this after unexporting and before unmounting. >> >> Seems like administrators would expect that a filesystem can be >> unmounted immediately after unexporting it. Should "exportfs" be changed >> to handle this extra step under the covers? Doesn't seem like it would >> be hard to do, and I can't think of a use case where it would be >> harmful. > > No. I think that admins don't expect to lose all their NFS client's state if > they're managing the exports. That would be a really big and invisible change > to existing behavior. To be clear, I mean that a file system should be unlocked only when it is specifically unexported. IMO, unexport is usually an administrator action that means "I want to stop remote access to this file system now" and that's what unlock_filesystem does. IMO administrators would be surprised to learn that NFS clients may continue to access a file system (via existing open files) after it has been explicitly unexported. The alternative is to document unlock_filesystem in man exportfs(8). And perhaps we need a more surgical mechanism that can handle the case where the file system is still exported but the security policy has changed. Because this does feel like a real information leak. -- Chuck Lever
