Dell Unity: cannot access files or folders in NFS export after upgrade to Unity OE 5.5

• Users may notice that some files cannot be accessed or folders cannot be listed after Unity upgrading to Operating Environment (OE) 5.5
• The issue only happens under the following conditions: 
  • Client mounts the NFS Export using NFSv4.2, the access is good if the client mounts the NFS export using NFSv3, or NFSv4.0, or NFSv 4.1.  
  • SELinux is enabled on the Linux client. 

Here is an example:

• User test_user cannot list the content of NFS mountpoint /mnt when mounting using NFSv4.2. 

[test_user@RHEL4 ~]$ mount -v | grep -i mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.60.15.48)

[test_user@RHEL4 ~]$ ls -al /mnt
ls: cannot open directory '/mnt': Permission denied

• User test_user can list the same folder after client remounting the NFS export using NFSv4.1.

[test_user@RHEL4 ~]$ mount -v | grep -i mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.60.15.48)


[test_user@RHEL4 ~]$ ls -al /mnt
total 16
drwxrwxrwx.  6 root root 8192 Jun 18 03:21 .
dr-xr-xr-x. 20 root root  271 Jun  8 19:07 ..
dr-xr-xr-x.  2 root bin   152 Apr 14 03:56 .etc
drwxr-xr-x.  2 root root  152 Jun 18 03:20 folder
drwxr-xr-x.  2 root root 8192 Apr 14 03:56 lost+found

• Unity added support for NFSv4.2 starting with Unity OE 5.5. NFSv4.2 protocol support brings additional security and performance, and NFS attribute support of spare files and NFS labeling.
• The security label feature in NFSV4.2 allows security labels (such as SELinux contexts) to be stored and enforced over NFS shares. By default, this feature is enabled on Unity NAS server. 
• When SELinux is enabled on a Linux client, it assigns a security label to every object in the systems including files, folders, processes, ports, and devices. 
• The default security context that SELinux assigns to files in NFS export mounted using NFS v3, V4.0, or v4.1 is system_u:object_r:nfs_t:s0.

[root@rhel8 test]# ls -alZ testv4.1
-rw-r--r--. 1 root root system_u:object_r:nfs_t:s0 0 Jun  1 21:47 testv4.1

• When the client mounts the NFS Export using NFS v4.2, the default security context of NFS files changes to unconfined_u:object_r:default_t:s0.

[root@rhel8 test]# ls -alZ testv4.2
-rw-r--r--. 1 root root unconfined_u:object_r:default_t:s0 0 Jun  1  2025 testv4.2

• The change of the security context especially the security type from nfs_t to default_t may cause some access issues as SELinux determines the access permission based on the policy rules that calculates the security type of the user or process and files or folders.

• This issue is fixed in Unity OE 5.5.3. 
  • Release Notes for the Dell Unity™ Family Current Release Version: 5.5.3.0.5.046 

If an upgrade is not an option, there are workarounds to avoid this issue.
Users should choose one solution based on their priorities: security, simplicity, or feature requirements. 
 

• Remount the NFS export using NFSv4.1, NFSv4.0, or NFSv3 from client:

mount -o vers=4.1 <nas server IP>:/<export> /<localmountpoint>

• Mount the NFS export using NFSv4.2 but specify the security context:

mount -o context=system_u:object_r:nfs_t:s0 <nas server IP>:/<export> /<localmountpoint>

• Downgrade the maximum support NFSv4 version on Unity from v4.2 to v4.1.
  • Dell Unity: After upgrade to Unity OE version 5.5, NFSv4 clients cannot access data

• Disable the security label on Unity:
  • Dell Unity: How to disable Security Label over NFS on Unity OE 5.5 (User Correctable)

• Change the security type of the files in NFS export to the appropriate ones based on the requirement:

chcon <user>:<role>:<type>:<level> <file/folders>

For example, change the file type to nfs_t. 

[root@RHEL4 /]# ls -alZ /mnt/nfsv4.2
-rw-r--r--. 1 root root system_u:object_r:default_t:s0 0 Jun 17 00:53 /mnt/nfsv4.2
[root@RHEL4 /]# chcon -t nfs_t /mnt/nfsv4.2
[root@RHEL4 /]# ls -alZ /mnt/nfsv4.2
-rw-r--r--. 1 root root system_u:object_r:nfs_t:s0 0 Jun 17 00:53 /mnt/nfsv4.2

The following procedure can be followed to troubleshoot the SELinux access issue. 

1. Determine the security context of the user:

[test_user@RHEL4 ~]$ id -Z
user_u:user_r:user_t:s0

2. Confirm that the NFS export is mounted using NFSv4.2 and seclabel is enabled:

[test_user@RHEL4 ~]$ mount -v | grep mnt
10.xx.xx.48:/test on /mnt type nfs4 (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.227.xxx.129,local_lock=none,addr=10.xx.xx.48)

3. Check the file security context and reproduce the issue:

[test_user@RHEL4 ~]$ ls -aldZ /mnt
drwxrwxrwx. 6 root root system_u:object_r:default_t:s0 8192 Jun 17 07:44 /mnt

[test_user@RHEL4 ~]$ ls -al /mnt
ls: cannot open directory '/mnt': Permission denied

4. Check auditlog to confirm why the command fails:

[root@RHEL4 ~]# ausearch -m avc -ts recent | tail
----
time->Tue Jun 17 18:30:59 2025
type=PROCTITLE msg=audit(1750xxxx59.577:8407): proctitle=6C73002D2D636F6C6F723Dxxxxx46F002D616C002F6D6E74
type=SYSCALL msg=audit(1750203059.577:8407): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5563f160ca70 a2=90800 a3=0 items=0 ppid=104637 pid=104661 auid=10086 uid=10086 gid=10086 euid=10086 suid=10086 fsuid=10086 egid=10086 sgid=10086 fsgid=10086 tty=pts1 ses=246 comm="ls" exe="/usr/bin/ls" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1750xxxx59.577:8407): avc:  denied  { read } for  pid=104661 comm="ls" name="/" dev="0:47" ino=2 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0

5. When the user runs ls on the /mnt, the ls process inherits the user's security type, the SELinux system determines if the security type user_t has read permission on the file type default_t. In this case, the ls command failed because the source security type user_t does not have read permission on the file's security type default_t. 

This can be confirmed by checking the security policy rules:

root@RHEL4 ~]# sesearch -A -s user_t -t default_t -p read
[root@RHEL4 ~]#

6. The following command lists all the permissions type user_t has on type default_t.

[root@RHEL4 ~]# sesearch -A -s user_t -t default_t
allow domain base_file_type:dir { getattr open search };  
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow user_usertype file_type:filesystem getattr;

7. In the above output, user_t belongs to domain, and default_t belongs to base_file_type.
   So, user_t only has getattr, open, search permission on the directory with default_t type.

[root@RHEL4 mnt]# seinfo -t default_t -x

Types: 1
   type default_t, base_file_type, file_type, mountpoint, non_auth_file_type, non_security_file_type;


[root@RHEL4 mnt]# seinfo -t user_t -x | grep domain
   type user_t, application_domain_type, nsswitch_domain, corenet_unlabeled_type, domain, kernel_system_state_reader, netlabel_peer_type, privfd, process_user_target, scsi_generic_read, scsi_generic_write, syslog_client_type, pcmcia_typeattr_1, user_usertype, login_userdomain, userdomain, unpriv_userdomain, userdom_home_reader_type, userdom_filetrans_type, xdmhomewriter, x_userdomain, x_domain, dridomain, xdrawable_type, xcolormap_type;
/pre>

8. User can cd to /mnt since open is allowed. 

>allow domain base_file_type:dir { getattr open search };   <<<<

[test_user@RHEL4 ~]$ cd /mnt
[test_user@RHEL4 mnt]$ ls
ls: cannot open directory '.': Permission denied