Hey folks, looking at this thread I see in general VFS rootless is pretty much not possible. I went ahead and tried to launch a container with the root namespace capabilities and then provide from podman all the necessary capabilities to the container so ganesha could run with privilege. Of course I'm still having issues with the filehandle. That being said in the thread here: https://lists.nfs-ganesha.org/archives/list/support@lists.nfs-ganesha.org/th... there is a comment that I'm particularly interested in as it is in line with my specific use case and I was wondering if there is any more information on this? " We DO have a new capability to build without that need (it doesn't work on MacOS) and if you only needed to export files owned by a single user, it would be easy to setup Ganesha to do so, and if you needed to be able to export to non-owner users, we could probably make that work, especially if non-owners would be read-only. There are some complexities about writing to files, but I think they can be ignored in this use case (there may be some quota implications, but if an owner is allowing non-owners to expand files, the quota definitely should be assigned to the owner anyway, so doing the writes as the owner would be fine). But the only way to work around the CAP for open_by_handle is to add some kind of handle mapping. " In my case I would theoretically like to run a rootless container and share out a list of directories that are owned by the same rootless user running the container. I'm wondering if this is possible at all? Also just for the sake of including my debug information - config is a tad messy just trying to see if I can even ductape things together or not. EXPORT_DEFAULTS { ## Access type for clients. Default is None, so some access must be ## given either here or in the export itself. Access_Type = RW; Attr_Expiration_Time =0; } NFS_CORE_PARAM { fsid_device = true; } EXPORT { ## Export Id (mandatory, each EXPORT must have a unique Export_Id) Export_Id = 12345; ## Exported path (mandatory) Path = /exports/; ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true) Pseudo = /exports/; ## Restrict the protocols that may use this export. This cannot allow ## access that is denied in NFS_CORE_PARAM. # I didnt have any issues include nfsv3 - i was actually failing on showmount -e to show /exports if i had only 4?? Protocols = 3,4; ## Access type for clients. Default is None, so some access must be ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block Access_Type = RW; ## Allowed security types for this export Sectype = none; Squash = All; Anonymous_Uid = 0; Anonymous_Gid = 0; FSAL { Name = VFS; } CLIENT { Access_Type = RW; } } ## Configure logging. Default is to log to Syslog. Basic logging can also be ## configured from the command line LOG { ## Default log level for all components Default_Log_Level = INFO; ## Configure per-component log levels. Components { NFS4 = FULL_DEBUG; CACHE_INODE = FULL_DEBUG; EXPORT = FULL_DEBUG; FSAL = FULL_DEBUG; CONFIG = FULL_DEBUG; } ## Where to log Facility { name = FILE; destination = "/var/log/ganesha.log"; enable = active; } } [root@4e8602ae7a6b /]# ganesha.nfsd -v NFS-Ganesha Release = V4.0 run statement exec /usr/bin/ganesha.nfsd -F -L /dev/stderr -f /run/ganesha/ganesha.conf -p /run/ganesha/ganesha.pid [root@4e8602ae7a6b /]# showmount -e Export list for 4e8602ae7a6b: /exports (everyone) on mount: 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] vfs_getattr2 :FSAL :F_DBG :Calling find_fd, state = NULL 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] vfs_open_by_handle :FSAL :F_DBG :vfs_fs = /exports root_fd = 4 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] vfs_open_by_handle :FSAL :M_DBG :Handle len 22 0x45: fsid=0x00000000000000fd.0x0000000000000000, type 0x81, opaque: (12:0xb590b00c0000000033232ebf) 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] vfs_open_by_handle :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000000 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] find_fd :FSAL :DEBUG :Failed with Operation not permitted openflags 0x00000020 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] vfs_getattr2 :FSAL :F_DBG :Got fd -1 closefd = false 27/09/2022 16:42:56 : epoch 633327a7 : 4e8602ae7a6b : ganesha.nfsd-12[svc_10] fsal_common_is_referral :FSAL :EVENT :Failed to get attrs for referral, handle: 0x564e2c093d70, valid_mask: 0, request_mask: 82, supported: 0, error: Forbidden action Note on run path: from root run capsh script to launch podman ganesha container podman runs with capabilities all (as specific user) process / capability tree root - capsh user -podman run -> full capability set user - podman run reduced set based on binary capabilities (modified from none to ensure root namespace capabilities are not lost) - =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_setgid,cap_setuid,cap_net_bind_service,cap_net_admin ^^ I think I only need dac_read_search and maybe setgid/setuid however im just going overkill to make sure I have what I need nfs ganesha process then only is running based on getpcaps in the container with all the above capabilities