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