La racine ne peut pas modifier l'autorisation ou la propriété du fichier

Mon répertoire est root:

pwd 
/

J'ai le répertoire suivant:

drwxrwxrwx   4 root   root     81920 Jun  4 09:25 imr_report_repo

REMARQUE: imr_report_repo est un partage NFS.

Voici la fstabliste pour 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 fichier dans le montage:

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

L'UID 502 n'existe pas. Si nous ajoutons cet UID / GID localement:

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

Il apparaît maintenant:

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

Passez maintenant à root:

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

N'a généralement rootpas d'autorisations spéciales sur les partages NFS. Au contraire: rootest mappé à un utilisateur ordinaire (c'est-à-dire n'a même pas un accès "normal" en lecture et en écriture aux rootfichiers).

Vous devez exécuter chownsur le serveur NFS.

C'est généralement le cas que l'utilisateur racine local sur les clients NFS n'est pas autorisé à effectuer ces types d'activités sur les partages montés NFS. NetApp semble ajouter un peu de torsion à cela comme suit:

• Par défaut, l'option anon spécifie un UID de 65534. Autrement dit, si vous n'utilisez pas les options root et anon pour une ressource, les utilisateurs root sur tous les hôtes accèdent à la ressource à l'aide de l'UID 65534.
• Si l'option anon spécifie un UID de 65535, l'accès root est désactivé.
• Si l'option anon spécifie un UID de 0, l'accès root est accordé à tous les hôtes.
• Si un nom est fourni à la place d'un UID, ce nom est recherché selon l'ordre spécifié dans le /etc/nsswitch.conffichier pour déterminer l'UID correspondant à affecter par l'option anon.

Donc, à première vue, le partage NetApp NFS a l'option par défaut, # 1. Vous pouvez le confirmer en touchant un fichier sur le partage NFS en tant que root et en voyant quel ID en résulte.

Vous devriez pouvoir voir les options exportées du partage NFS à l'aide mount -vde votre client 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)

Références

• NFS: root Option - Communauté NetApp

Un serveur NetApp NFS va, par défaut, changer les informations d'identification de l'utilisateur root sur un client en uid 65534 sur le serveur, donc les opérations comme chownéchouent. Pour modifier cela, modifiez la liste d'exportation sur le filer afin que la ligne du système de fichiers ait le paramètre root=clientid, où clientid est l'adresse IP ou le nom d'hôte du client auquel vous souhaitez avoir un accès root sur ce système de fichiers. Exécutez ensuite exportfs -asi vous utilisez l'interface de ligne de commande sur le filer.

Comme l'a dit le commentaire slm ci-dessus,

Il est généralement le cas où l'utilisateur racine local sur les clients NFS n'est pas autorisé à effectuer ces types d'activités sur les partages montés NFS

La fonction utilisée est appelée pourriture courge . Plus d'informations ici . Dans mon cas, la seule façon était de se connecter pour désactiver le root squash pour ce serveur particulier et le réactiver plus tard.

Une situation similaire que vous rencontrerez si vous utilisez un dockerconteneur avec des volumes et que le conteneur s'exécute avec un utilisateur non privilégié (par exemple USER apache). L'idée que les points de montage NFS soient r/ wuniquement par owneret non par rootest une pratique de sécurité courante.