Table des matières
chown et "Argument invalide"
Un petit truc pas spécialement bien expliqué (sauf là) …
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.