I have a use case where I have an NFS4 mount that doesn't support ID mapping. Some of my NFS4 clients are "bare metal", and others are containers. All of the containers use user namespaces, so their UIDs don't match up with the UIDs used on the bare metal. This becomes problematic, especially when using third-party software. If the NFS4 sb's s_user_ns was the container's user ns, as opposed to the init user ns, it would solve this problem. In fact, the mount namespace of the container is associated with the container's user namespace. Are there any plans to make it so that there is a mount option to utilize the current mount ns's user ns, as opposed to the mounting process's user ns as s_user_ns? Although I don't want the user namespace to be able to mount NFS volumes, I think it's reasonable, and safe to orchestrate the mount from init user ns, and use my container user ns to interpret uids, and such. Alternatively, the shiftfs patches that are floating around would also solve this, but they don't seem ready yet. Alternatively, if it makes sense to make s_user_ns swappable via an ioctl, I'd be in support of that as well, but I'm not sure about potential issues (bar concurrency) associated with that. -Thanks, Sargun
