Hi,
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.
The machine hosts a regular NFS v3 and v4 service that should not be
bothered with this task (and it cannot access the FUSE-based mount in
the namespace that should be exported, and probably should not for
containment/security reasons).
I figured that it should be possible to run a NFSv4 server on a
different TCP port than 2049, not needing further RPC port mapping.
I tried this:
NFS_CORE_PARAM {
Protocols = 4;
NFS_Port = 2050;
Enable_UDP = false;
Bind_addr = [some IP];
}
NFS_KRB5 {
Active_krb5 = false;
}
But soon realized that I am forced to specify additional values to make
ganesha.nfsd even try to start, even if I don't need rquota, for
example:
NFS_CORE_PARAM {
Rquota_Port = 8750;
# even for nfsv4, ganesha insists on rpcbind?!
NFS_Program = 200003;
Rquota_Program = 200001;
}
I can of course not use the default NFS_Program value, as that is
occupied by the main NFS instance. Well, at least I assume that from this error:
09/05/2026 18:00:53 : epoch 69ff5a35 : server : ganesha.nfsd-3213231[main] __Register_program :DISP :MAJ :Cannot register NFS V4 on TCP
When I run with this setup, the client can contact ganesha, but errors
out:
client:/# mount -o nfsvers=4.2,proto=tcp,port=2050,ro server:/mount /mount
mount.nfs: Protocol family not supported
And I see this message in ganesha log with -N FULL_DEBUG:
09/05/2026 17:48:28 : epoch 69ff5747 : server : ganesha.nfsd-3207650[svc_6] nfs_rpc_noprog :DISP :F_DBG :Invalid Program number 100003
This suggests that I still do have a conflict with the RPC program
100003 … I am not that intimate with the details of the NFS protocol.
The client does not need to RPC portmap, but the RPC stuff is still
needed on the server and prevents multiple instances of NFS servers on
one system?
What is NFS_Program even for when client mount requests result in
Program number 100003 being tried, anyway? Is there another trick I
need to add to make this work?
When I don't specify NFS_Program to a different value, the client gets
mount.nfs: mounting server:/mount failed, reason given by server: No such file or directory
I see
09/05/2026 18:03:48 : epoch 69ff5aaf : server : ganesha.nfsd-3214122[svc_2] nfs_rpc_process_request :DISP :DEBUG :Request from ::ffff:[client_ip] for Program 100003, Version 4, Function 1 has xid=1120240127
This seems to imply that the client hardcodes program 100003. I don't
see an option for that in nfs(5). Could it be that a simple
modification in mount.nfs to add an option for the RPC program to call
would enable multiple instances of NFSv4 servers on one system, and
that right now the presense of NFS_Program in ganesha config doesn't
serve a purpose, at least with Linux kernel clients?
Alrighty then,
Thomas
PS: I have this very setup running with Samba smbd in the namespace
kistening on a non-standard port instead of NFS, wich works in principle,
but the share needs to support file names with ':' in them, and POSIX
semantics in general, so that I figured NFS would be the choice after
all. The v9fs Linux client has some warnings to it regarding robustness
that make me hesitate to switch to that protocol.
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
