Root no puede cambiar el permiso o la propiedad del archivo

Mi directorio es root:

pwd 
/

Tengo el siguiente directorio:

drwxrwxrwx   4 root   root     81920 Jun  4 09:25 imr_report_repo

NOTA: imr_report_repo es un recurso compartido NFS.

Aquí está la fstablista de imr_report_repo:

netapp1:/imr_report_repos_stage  /imr_report_repo  nfs   rw,bg,actimeo=0,nointr,vers=3,timeo=600,rsize=32768,wsize=32768,tcp 1    1
d imr_report_repo

Un archivo dentro de mount:

$ ls -al
-rw-r--r--  1 502     502      1273 Mar 21  2013 imr1_test.txt

El UID 502 no existe. Si agregamos ese UID / GID localmente:

$ groupadd -g 502 jimmy
$ useradd -g 502 -u 502 jimmy

Ahora aparece:

$ ls -al
-rw-r--r--  1 jimmy     jimmy      1273 Mar 21  2013 imr1_test.txt

Ahora cambie a root:

$ su -
$ chown oracle:oinstall imr1_test.txt
chown: changing ownership of `imr1_test.txt': Operation not permitted

Por rootlo general , no tiene permisos especiales en recursos compartidos NFS. Por el contrario: rootse asigna a un usuario común (es decir, ni siquiera tiene acceso de lectura y escritura "normal" a los rootarchivos).

Debe ejecutar chownen el servidor NFS.

Por lo general, el usuario raíz local en clientes NFS no puede realizar este tipo de actividades en recursos compartidos montados en NFS. NetApp parece agregar un poco de giro en esto de la siguiente manera:

• De forma predeterminada, la opción anon especifica un UID de 65534. Es decir, si no usa las opciones de root y anon para un recurso, los usuarios root en todos los hosts acceden al recurso usando el UID 65534.
• Si la opción anon especifica un UID de 65535, el acceso raíz está deshabilitado.
• Si la opción anon especifica un UID de 0, se otorga acceso de root a todos los hosts.
• Si se proporciona un nombre en lugar de un UID, ese nombre se busca de acuerdo con el orden especificado en el /etc/nsswitch.confarchivo para determinar el UID correspondiente que se asignará mediante la opción anon.

Por lo que parece, el recurso compartido NFS de NetApp tiene la opción predeterminada, # 1. Puede confirmar esto tocando un archivo en el recurso compartido NFS como root y viendo qué ID resulta de hacer esto.

Debería poder ver las opciones exportadas del recurso compartido NFS mount -ven su cliente NFS.

$ mount -v
...
mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=192.168.1.1)

Referencias

• NFS: opción raíz - Comunidad de NetApp

Un servidor NFS de NetApp, por defecto, cambiará las credenciales del usuario raíz en un cliente a uid 65534 en el servidor, por lo que las operaciones como chownfallarán. Para cambiar esto, edite la lista de exportación en el archivador para que la línea del sistema de archivos tenga el parámetro root=clientid, donde clientid es la dirección IP o el nombre de host del cliente al que desea tener acceso raíz a ese sistema de archivos. Luego, ejecute exportfs -asi está utilizando la interfaz de línea de comandos en el archivador.

Como dijo el comentario de slm arriba,

Por lo general, el usuario raíz local en clientes NFS no puede realizar este tipo de actividades en recursos compartidos montados en NFS

La característica utilizada se llama podredumbre . Más información aquí . En mi caso, la única forma era iniciar sesión para deshabilitar el root squash para este servidor en particular y habilitarlo de nuevo más tarde.

Una situación similar se encontrará si usa un dockercontenedor con volúmenes y el contenedor se ejecuta con un usuario sin privilegios (por ejemplo USER apache). Por lo tanto, la idea de que los puntos de montaje NFS sean r/ wsolo por el owner, y no por, rootes una práctica de seguridad común.