Table des matières

chown et "Argument invalide"

Un petit truc pas spécialement bien expliqué (sauf ) …

Sur un montage nfs , avec un système relativement récent, on peut tomber sur une erreur comme ça:

# chown nobody:nogroup /mnt/tmp/bla
chown: modification du propriétaire de « /mnt/tmp/bla »: Argument invalide

Pourtant, on est “root” et ce partage “nfs” est banal: “root” devrait avoir tout les droits, y compris celui de changer le propriétaire d'un répertoire ou d'un fichier.

Ah bah non: Pas forcément avec “nfs4” .

A ma connaissance, il y a 2 solutions:

~~READMORE~~

Retour sur nfs3

La plus simple, mais pas la meilleure.

Rétro-pédaler sous nfs3 en ajoutant “mountvers=3,nfsvers=3” aux options de montage…

Exemple:

# umount /mnt/tmp
# mount -t nfs -o mountvers=3,nfsvers=3 192.168.1.177:/mnt/partage /mnt/tmp

Maintenant, “chown” devrait fonctionner.

Désactiver l'idmapping

Le mieux: désactiver le “idmapping” .

Selon les environnements (par exemple “Debian Jessie”), c'est parfois le cas par défaut.
Mais sur d'autres, comme “Debian Wheezy”, non.

Vérifier l'état de l'"idmapping"

# cat /sys/module/nfs/parameters/nfs4_disable_idmapping 
N

On constate qu'il est en service… “disable=N” → “enable=Y:-?

Si c'est “Y” ou “1” , alors le problème avec “chown” est ailleurs.

Désactiver l'"idmapping"

Immédiatement

# echo 1 > /sys/module/nfs/parameters/nfs4_disable_idmapping

Oui, parce que “disable=Y” (ou “1”) → “enable=N;-)

Maintenant, il faut remonter le partage “nfs” , et ça devrait fonctionner.

Persistant après reboot

Pour que l'“idmapping” reste désactivé même après les reboot futurs.

# echo "options nfs nfs4_disable_idmapping=1" > /etc/modprobe.d/99-nfs.conf

Au prochain reboot , (ou si vous décharger et recharger le module “nfs”) l'“idmapping” sera désactivé.

NOTA:
Sous Debian Wheezy, et Jessie, je n'ai pas trouvé comment rendre ça possible :

sysctl nfs.nfs4_disable_idmapping=1

… peut être pour le prochain noyau ?

Voila.