1:15 p.m.
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?
8:01 a.m.
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(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
2:32 p.m.
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.
1 p.m.
On Mon, Feb 22, 2021 at 3:37 PM vaf0001--- via Support <
support(a)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
1:06 p.m.
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;
9:26 p.m.
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-ganesh...
# ----------------------------------------------------------------
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(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
--
Thx,
TK.
1389
days inactive
1399
days old
5 comments
4 participants
participants (4)
-
Daniel Gryniewicz -
Kaleb Keithley -
TomK -
vaf0001＠uah.edu