Dead-end conclusion follows … Am Thu, 28 May 2026 15:31:23 +0200 schrieb "Dr. Thomas Orgis via Devel" <devel@lists.nfs-ganesha.org>:
Am Wed, 20 May 2026 12:05:27 +0200 schrieb "Dr. Thomas Orgis via Devel" <devel@lists.nfs-ganesha.org>:
I am investigating the option of running nfs-ganesha in an unprivileged user/mount namespace on Linux, to export some directory only visible there, in addition to a main NFS server on the same host. It should be a simple world-readable share, no security considerations client-side.
[…]
It looks like I'll not use NFS-Ganesha at all in the end, but it would be nice to have a confirmation about the technical reasons why the attempt to isolate NFS serving of a FUSE mount in a unprivileged namespace has to fail … or how it could work instead.
I finally managed to come up with a config that _should_ work, but hits an roadblock that should have been obvious in retrospect: NFS_CORE_PARAM { Protocols = 4; NFS_Port = 2050; Enable_UDP = false; # Must configure a port for rquota or startup fails, cannot disable rquota. Rquota_Port = 8750; Rquota_Program = 200001; # Also, dbus registration fails without root, but no way to configure it out. } NFS_KRB5 { Active_krb5 = false; CCacheDir = /some/place/ganesha-ccache; } NFSv4 { RecoveryRoot = /some/placeganesha-var; } EXPORT { Export_Id = 0; Path = /srv/foo; Pseudo = /; Access_Type = RO; SecType = sys; Protocols = 4; FSAL { name = PSEUDO; } } EXPORT { Export_Id = 77; Path = /srv/foo/mount; Pseudo = /mount; Access_Type = RO; SecType = sys; Protocols = 4; FSAL { Name = VFS; } } This works … except that ganesha cannot get file handles: 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] vfs_open_by_handle :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000000 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] find_fd :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000020 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] fsal_common_is_referral :FSAL :EVENT :Failed to get attrs for referral, handle: 0x56328fcb8cf0, valid_mask: 0, request_mask: 82, supported: 0, error: Forbidden action 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] complete_op :NFS4 :DEBUG :Status of OP_GETFH in position 3 = NFS4_OK, op response size is 32 total response size is 128 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] process_one_op :NFS4 :DEBUG :Request 4: opcode 9 is OP_GETATTR 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] file_To_Fattr :NFS4 ACL :DEBUG :No permission check for ACL for obj 0x56328fcc0ef8 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] vfs_open_by_handle :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000000 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] find_fd :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000020 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] fsal_common_is_referral :FSAL :DEBUG :Checking attrs for referral, handle: 0x56328fcb8cf0, valid_mask: 0, request_mask: 82, supported: 0 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] vfs_open_by_handle :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000000 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] find_fd :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000020 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] fsal_common_is_referral :FSAL :EVENT :Failed to get attrs for referral, handle: 0x56328fcb8cf0, valid_mask: 0, request_mask: 82, supported: 0, error: Forbidden action 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] complete_op :NFS4 :DEBUG :Status of OP_GETATTR in position 4 = NFS4ERR_PERM, op response size is 4 total response size is 136 01/06/2026 11:38:41 : epoch 6a1d51c0 : server : ganesha.nfsd-895547[svc_13] complete_nfs4_compound :NFS4 :DEBUG :End status = NFS4ERR_PERM lastindex = 5 And, sure enough, reading up on the error on the first line leads me to https://github.com/nfs-ganesha/nfs-ganesha/wiki/VFS mentioning that ganesha needs CAP_DAC_READ_SEARCH, which is defined as CAP_DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks; - invoke open_by_handle_at(2); - use the linkat(2) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor. So … this kindof defeats the idea of running the NFS server as unprivileged user. It would indeed be interesting to know why open_by_handle_at() needs to be coupled with read permissions on EVERYTHING. It is really sad that there used to be a FUSE FSAL … which could have directly exposed the FUSE fs I am working with, without having to mount it one the server and having to play with namespaces to allow that at all. This would have been great! Sad that the FUSE FSAL had to go. I don't see me coding up a direct FSAL for the respective fs when it is already written to FUSE API. Or, to return to the VFS route … were there ever attempts to decouple open_by_handle_at() from the broad read permission on everything in Linux? So it will be a separate server with kernel NFS to get some separation of concerns for me, then … or a full-blown VM with one exported TCP port. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg