Dead-end conclusion follows …
Am Thu, 28 May 2026 15:31:23 +0200
schrieb "Dr. Thomas Orgis via Devel" <devel(a)lists.nfs-ganesha.org>:
Am Wed, 20 May 2026 12:05:27 +0200
schrieb "Dr. Thomas Orgis via Devel" <devel(a)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