On Sat, 19 Mar 2022, Chuck Lever III wrote: > > Here are some suggestions that might make it simpler to implement. > > 1. Ben's tool manufactures the uniqifier if the file doesn't > already exist. That seems somewhat racy. Instead, why not > make installation utilities responsible for creating the > uniquifier? We need some guarantee that when a VM is cloned, > the uniquifier is replaced, for instance; that's well > outside nfs-utils' sphere of influence. You say "the file" like that is a well defined concept. It isn't. In the context of a container we don't even know if there is *any* stable local storage. The existence of "the file" is as much out side of nfs-util's sphere of influence as the cloning of a VM is. At least the cloning of a VM is, or soon will be (https://lwn.net/Articles/887207/), within the sphere of influence of the NFS kernel module. It will be able to detect the fork and .... do something. Maybe disable access to all existing mounts and refuse new mounts until 'identity' has been set. If NFS had always required identity to be set in a container before allowing mounts, then the udev approach could work and we would be in a much better place. But none of us knew that then, and it is too late for that now (is it?). This conversation seems to be going around in circles and not getting anywhere. As as I have no direct interest (the SUSE bugzilla has precisely 1 bug relating to NFS and non-unique hostnames, and the customer seemed to accept the requirement of unique hostnames) I am going to bow out. I might post one more attempt at a documentation update ... or I might not. Thanks, NeilBrown
