Dell Unity: no se puede acceder a archivos o carpetas en la exportación NFS después de la actualización a Unity OE 5.5

Resumen: Es posible que el usuario de Linux no pueda acceder a algunos archivos o carpetas en la exportación del sistema de archivos de red (NFS) después de actualizar a Unity OE 5.5.

Este artículo se aplica a Este artículo no se aplica a Este artículo no está vinculado a ningún producto específico. No se identifican todas las versiones del producto en este artículo.

Síntomas

  • Es posible que los usuarios observen que no se puede acceder a algunos archivos o que no se pueden enumerar las carpetas después de la actualización de Unity al entorno operativo (OE) 5.5
  • El problema solo se produce en las siguientes condiciones: 
    • El cliente monta la exportación NFS mediante NFSv4.2, el acceso es correcto si el cliente monta la exportación NFS mediante NFSv3o NFSv4.0o NFSv 4.1.  
    • SELinux está habilitado en el cliente Linux. 

He aquí un ejemplo:

  • Usuario test_user no se puede enumerar el contenido del punto de montaje de NFS /mnt Cuando se monta mediante 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
  • Usuario test_user puede enumerar la misma carpeta después de que el cliente vuelva a montar la exportación NFS mediante 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

Causa

  • Unity agregó compatibilidad con lo siguiente: NFSv4.2 a partir de Unity OE 5.5. NFSv4.2 La compatibilidad con protocolos aporta seguridad y rendimiento adicionales, y compatibilidad con atributos NFS de archivos de repuesto y etiquetado NFS.
  • La función de etiqueta de seguridad en NFSV4.2 Permite etiquetas de seguridad (como SELinux contextos) que se almacenarán y aplicarán a través de recursos compartidos NFS. De manera predeterminada, esta característica está habilitada en el servidor NAS de Unity. 
  • Cuando… SELinux está habilitado en un cliente Linux y asigna una etiqueta de seguridad a cada objeto de los sistemas, incluidos archivos, carpetas, procesos, puertos y dispositivos. 
  • El contexto de seguridad predeterminado que SELinux asigna a archivos en la exportación NFS montada mediante NFS v3, V4.0o v4.1 es 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
  • Cuando el cliente monta la exportación NFS mediante NFS v4.2, el contexto de seguridad predeterminado de los archivos NFS cambia a 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
  • El cambio del contexto de seguridad, especialmente el tipo de seguridad de nfs_t como default_t Puede causar algunos problemas de acceso, ya que SELinux Determina el permiso de acceso en función de las reglas de políticas que calculan el tipo de seguridad del usuario o el proceso y los archivos o carpetas.

Resolución

En la página 2 de las notas de la versión, se muestra que se solucionó este problema

 

Si una actualización no es una opción, existen soluciones alternativas para evitar este problema.
Los usuarios deben elegir una solución en función de sus prioridades: seguridad, simplicidad o requisitos de características. 
 

  • Vuelva a montar la exportación NFS mediante NFSv4.1, NFSv4.0, or NFSv3 Del cliente:
mount -o vers=4.1 <nas server IP>:/<export> /<localmountpoint>
  • Monte la exportación de NFS mediante NFSv4.2 Pero especifique el contexto de seguridad:
mount -o context=system_u:object_r:nfs_t:s0 <nas server IP>:/<export> /<localmountpoint>
  • Cambie el tipo de seguridad de los archivos en la exportación NFS a los correspondientes según el requisito:
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

Información adicional

Se puede seguir el siguiente procedimiento para solucionar problemas de SELinux Problema de acceso. 

1. Determine el contexto de seguridad del usuario:

[test_user@RHEL4 ~]$ id -Z
user_u:user_r:user_t:s0
  1. Confirme que la exportación NFS se monte mediante NFSv4.2 y seclabel está habilitado:
[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)
  1. Compruebe el contexto de seguridad del archivo y reproduzca el problema:
[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
  1. Compruébalo auditlog Para confirmar por qué falla el comando:
[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
  1. Cuando el usuario ejecuta ls En el /mntel ls hereda el tipo de seguridad del usuario, el método SELinux El sistema determina si el tipo de seguridad user_t Tiene permiso de lectura en el tipo de archivo default_t. En este caso, el método ls El comando falló porque el tipo de seguridad de origen user_t No tiene permiso de lectura en el tipo de seguridad del archivo default_t

Esto se puede confirmar mediante la comprobación de las reglas de la política de seguridad:

root@RHEL4 ~]# sesearch -A -s user_t -t default_t -p read
[root@RHEL4 ~]#
  1. El siguiente comando enumera todos los tipos de permisos user_t tiene en el tipo 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;
  1. En la salida anterior, user_t pertenece al dominio, y default_t pertenece a base_file_type.
    Así que user_t solo tiene getattr, abra, permiso de búsqueda en el directorio con default_t tipo.
[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>
  1. El usuario puede: cd como /mnt ya que se permite abrir. 
>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

Productos afectados

Dell EMC Unity, Dell Unity Operating Environment (OE)
Propiedades del artículo
Número del artículo: 000334013
Tipo de artículo: Solution
Última modificación: 04 feb 2026
Versión:  3
Encuentre respuestas a sus preguntas de otros usuarios de Dell
Servicios de soporte
Compruebe si el dispositivo está cubierto por los servicios de soporte.