Server does not export
Folks, We have been hit with a recent Fedora Linux kernel bug rendering the built-in NFS server unstable. After some web search I found this userspace replacement. Unfortunately, I am unable to get the server to do anything useful, like export a filesystem. I've created the following test config file: EXPORT { Export_Id = 10; Path = /srv/nfs/home; Pseudo = /home; Access_Type = RW; Squash = no_root_squash; } LOG { Default_Log_Level = DEBUG; Facility { name = FILE; destination = "/var/log/ganesha/ganesha.log"; enable = active; } } The service (called nfs-ganesha.service on Fedora) starts just fine and I see no errors of any kind in the log file. But /srv/nfs/home is not exported. I've checked with "ganesha_mgr show exports", which produces the following output: Exports: Id, path, nfsv3, mnt, nlm4, rquota,nfsv40, nfsv41, nfsv42, 9p, last 0, /, 0, 0, 0, 0, 0, 0, 0, 0, Sun Feb 21 12:51:38 2021, 642993774 nsecs On a client, I cannot mount "servername:/home" (no such directory), only "servername:/" (which is empty). Can anyone provide some guidance?
Your export does not have a FSAL, so there's nothing to export. I assume this is a local filesystem you want to export, since you were using knfsd, so try adding this to your export block: FSAL { Name = VFS; } Daniel On 2/21/21 2:15 PM, vaf0001--- via Support wrote:
Folks,
We have been hit with a recent Fedora Linux kernel bug rendering the built-in NFS server unstable. After some web search I found this userspace replacement. Unfortunately, I am unable to get the server to do anything useful, like export a filesystem. I've created the following test config file:
EXPORT { Export_Id = 10; Path = /srv/nfs/home; Pseudo = /home; Access_Type = RW; Squash = no_root_squash; }
LOG { Default_Log_Level = DEBUG; Facility { name = FILE; destination = "/var/log/ganesha/ganesha.log"; enable = active; } }
The service (called nfs-ganesha.service on Fedora) starts just fine and I see no errors of any kind in the log file. But /srv/nfs/home is not exported. I've checked with "ganesha_mgr show exports", which produces the following output:
Exports: Id, path, nfsv3, mnt, nlm4, rquota,nfsv40, nfsv41, nfsv42, 9p, last 0, /, 0, 0, 0, 0, 0, 0, 0, 0, Sun Feb 21 12:51:38 2021, 642993774 nsecs
On a client, I cannot mount "servername:/home" (no such directory), only "servername:/" (which is empty). Can anyone provide some guidance? _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
Thank you for the advice - it got me past that obstacle. After a bit of fighting with SELinux (nfs-ganesha wanted some fuse access privileges) I managed to have a filesystem exported. However, I am now having trouble with permissions on the client (no user, including root, is allowed to change to the mounted directory). I guess this has to do with id mapping. When the server starts, it prints this message init_server_pkgs :NFS STARTUP :EVENT :Initializing ID Mapper. init_server_pkgs :NFS STARTUP :EVENT :ID Mapper successfully initialized. so it appears it is using its own mapper because the system one is not running. But how do I configure it to work properly? The kernel NFS server requires no configuration of id mapping, but here I am at a loss.
On Mon, Feb 22, 2021 at 3:37 PM vaf0001--- via Support < support@lists.nfs-ganesha.org> wrote:
Thank you for the advice - it got me past that obstacle. After a bit of fighting with SELinux (nfs-ganesha wanted some fuse access privileges)
Did you install the nfs-ganesha-selinux package? If yes and you're still seeing selinux AVCs then please put selinux in permissive mode (either edit /etc/selinux/config and change the SELINUX= line and reboot, or run `setenforce 0`) Then start ganesha and do whatever it is you were doing. Afterwards run `audit2allow -a` and attach the output to an issue at https://github.com/nfs-ganesha/nfs-ganesha/issues -- Kaleb
OK, I finally found the time to revisit this issue. Indeed, it appears the SELinux policy was not sufficient to allow access to the filesystem. I have posted the relevant output on the github. Here is it, in case someone else is having similar issues: module ganesha-extra 1.0; require { type ipmi_device_t; type user_home_dir_t; type unlabeled_t; type ganesha_t; type fuse_device_t; type efivarfs_t; type dosfs_t; type var_t; type tracefs_t; type device_t; type home_root_t; class dir { getattr read }; class file getattr; class blk_file getattr; class chr_file getattr; class filesystem getattr; } #============= ganesha_t ============== allow ganesha_t device_t:blk_file getattr; allow ganesha_t dosfs_t:dir getattr; allow ganesha_t dosfs_t:filesystem getattr; allow ganesha_t efivarfs_t:dir getattr; allow ganesha_t efivarfs_t:filesystem getattr; allow ganesha_t fuse_device_t:chr_file getattr; allow ganesha_t home_root_t:dir read; allow ganesha_t ipmi_device_t:chr_file getattr; allow ganesha_t tracefs_t:dir getattr; allow ganesha_t tracefs_t:filesystem getattr; allow ganesha_t unlabeled_t:dir getattr; allow ganesha_t unlabeled_t:file getattr; allow ganesha_t user_home_dir_t:dir getattr; allow ganesha_t var_t:dir read;
The way I've delt with SELinux when enforcing is through the following set of commands: # ---------------------------------------------------------------- nfs01 / nfs02 / nfs03 Run any of the following command, or a combination of, on deny entries in /var/log/audit/audit.log that may appear as you stop, start or install above services: METHOD 1: grep AVC /var/log/audit/audit.log | audit2allow -M systemd-allow semodule -i systemd-allow.pp # ---------------------------------------------------------------- https://microdevsys.com/wp/glusterfs-configuration-and-setup-w-nfs-ganesha-f... # ---------------------------------------------------------------- Using the first method, allowed me to get through virtually all of them. However, that is not a replacement to the nfs-ganesha-selinux package. Just the same, 3 years running now and on version NFS Ganesha 3.4 I'm quite happy. I've included the SELinux rules enabled on my nodes, in case this helps here. [root@nfs01 ~]# semanage fcontext -l|grep -Ei "nfs|ganesha" /var/lib/nfs(/.*)? all files system_u:object_r:var_lib_nfs_t:s0 /var/log/ganesha.log regular file system_u:object_r:ganesha_var_log_t:s0 /usr/bin/ganesha.nfsd regular file system_u:object_r:ganesha_exec_t:s0 /var/log/ganesha.log.* regular file system_u:object_r:ganesha_var_log_t:s0 /var/log/ganesha(/.*)? all files system_u:object_r:ganesha_var_log_t:s0 /var/run/ganesha(/.*)? all files system_u:object_r:ganesha_var_run_t:s0 /var/log/ganesha-gfapi.log.* regular file system_u:object_r:ganesha_var_log_t:s0 /var/lib/nfs/rpc_pipefs(/.*)? all files <<None>> /usr/lib/nfs-utils/scripts(/.*)? all files system_u:object_r:bin_t:s0 /usr/lib/systemd/system/nfs.* regular file system_u:object_r:nfsd_unit_file_t:s0 /usr/share/munin/plugins/nfs.* regular file system_u:object_r:system_munin_plugin_exec_t:s0 /usr/lib/systemd/system/nfs-ganesha.*e regular file system_u:object_r:ganesha_unit_file_t:s0 /usr/lib/systemd/system/nfs-ganesha-lock.* regular file system_u:object_r:ganesha_unit_file_t:s0 /usr/lib/systemd/system/nfs-ganesha-config.* regular file system_u:object_r:ganesha_unit_file_t:s0 /var/tmp/nfs_0 regular file system_u:object_r:krb5_host_rcache_t:s0 /usr/sbin/rpc\.nfsd regular file system_u:object_r:nfsd_exec_t:s0 /etc/rc\.d/init\.d/nfs regular file system_u:object_r:nfsd_initrc_exec_t:s0 /usr/sbin/rpc\.mountd regular file system_u:object_r:nfsd_exec_t:s0 /etc/rc\.d/init\.d/nfslock regular file system_u:object_r:rpcd_initrc_exec_t:s0 /usr/share/cluster/svclib_nfslock regular file system_u:object_r:bin_t:s0 /etc/rc\.d/init\.d/mountnfs-bootclean\.sh regular file system_u:object_r:tmpreaper_exec_t:s0 /usr/share/system-config-nfs/nfs-export\.py regular file system_u:object_r:bin_t:s0 /usr/share/system-config-nfs/system-config-nfs\.py regular file system_u:object_r:bin_t:s0 /var/log/ganesha all files system_u:object_r:ganesha_var_log_t:s0 /var/log/ganesha/ganesha.log all files system_u:object_r:ganesha_var_log_t:s0 /var/log/ganesha/ganesha-gfapi.log all files system_u:object_r:ganesha_var_log_t:s0 [root@nfs01 ~]# Thanks, On 3/1/2021 2:06 PM, vaf0001--- via Support wrote:
OK, I finally found the time to revisit this issue. Indeed, it appears the SELinux policy was not sufficient to allow access to the filesystem. I have posted the relevant output on the github. Here is it, in case someone else is having similar issues:
module ganesha-extra 1.0;
require { type ipmi_device_t; type user_home_dir_t; type unlabeled_t; type ganesha_t; type fuse_device_t; type efivarfs_t; type dosfs_t; type var_t; type tracefs_t; type device_t; type home_root_t; class dir { getattr read }; class file getattr; class blk_file getattr; class chr_file getattr; class filesystem getattr; }
#============= ganesha_t ============== allow ganesha_t device_t:blk_file getattr; allow ganesha_t dosfs_t:dir getattr; allow ganesha_t dosfs_t:filesystem getattr; allow ganesha_t efivarfs_t:dir getattr; allow ganesha_t efivarfs_t:filesystem getattr; allow ganesha_t fuse_device_t:chr_file getattr; allow ganesha_t home_root_t:dir read; allow ganesha_t ipmi_device_t:chr_file getattr; allow ganesha_t tracefs_t:dir getattr; allow ganesha_t tracefs_t:filesystem getattr; allow ganesha_t unlabeled_t:dir getattr; allow ganesha_t unlabeled_t:file getattr; allow ganesha_t user_home_dir_t:dir getattr; allow ganesha_t var_t:dir read; _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
-- Thx, TK.
participants (4)
-
Daniel Gryniewicz -
Kaleb Keithley -
TomK -
vaf0001＠uah.edu