chown: modifica della proprietà di `. ': argomento non valido

Sto cercando di installare alcuni nuovi file sul nostro nuovo server mentre il nostro amministratore di sistema è in vacanza:

Ecco il mio df

#  df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb3             273G   11G  248G   5% /
tmpfs                  48G  260K   48G   1% /dev/shm
/dev/sdb1             485M  187M  273M  41% /boot
xxx.xx.xxx.xxx:/commun
                       63T  2.2T   61T   4% /commun

come root , posso creare una nuova directory ed eseguire chownin / home / lindenb

# cd /home/lindenb/
# mkdir X
# chown lindenb X

ma non posso eseguire lo stesso comando in / commun

# cd /commun/data/users/lindenb/
# mkdir X
# chown lindenb X
chown: changing ownership of `X': Invalid argument

perché ? come posso risolvere questo?

aggiornato :

montare:

/dev/sdb3 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sdb1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
xxx.xx.xxx.xxx:/commun on /commun type nfs (rw,noatime,noac,hard,intr,vers=4,addr=xxx.xx.xxx.xxx,clientaddr=xxx.xx.xxx.xxx)

versione:

$ cat /etc/redhat-release 
CentOS release 6.3 (Final)

permissions chown

— Pierre
fonte

Digita mounte incolla l'output di questo nella tua domanda. Inoltre, su quale sistema operativo sei?

— jwbensley,

Non sono molto informato su NFS; Ma visto che / commun / data / users / lindenb / non è una directory locale sulla tua macchina, ma una condivisione di rete accessibile tramite NFS, inizierei esaminando le tue autorizzazioni sul server NFS (che è fuori dal mio ambito di conoscenza)

— jwbensley,

Risposte:

Il /communfile system è montato da un server remoto e il messaggio di errore suggerisce che potrebbe essere un mount nfsv4 (lo stesso per le versioni precedenti di nfs è Autorizzazione negata). Per impostazione predefinita, il file server remoto rootassocerà l' utente remoto a un nobodyaccount in modo che non possa modificare la proprietà del file.

La soluzione più semplice potrebbe essere quella di utilizzare l' lindenbaccount locale per creare le directory nella /commundirectory. Quindi come root

sudo -u linedb mkdir -p /commun/data/users/lindenb

Se il problema persiste, è possibile che si stia verificando una mappatura dell'ID, pertanto è possibile che sia necessario combinare le directory sul server xxx.xx.xxx.xxxe modificare la proprietà / autorizzazioni lì.

— user9517
fonte

grazie ma non ha funzionato sudo -u lindenb mkdir -p /commun/data/users/TMP mkdir: cannot create directory / commun / data / users / TMP ': Autorizzazione negata`

— Pierre

Il tuo punto su NFSv4 è un'aringa rossa ma sono d'accordo con il resto della risposta come corretto.

— DaveG,

grazie comunque per la tua risposta, non sono abbastanza abile da fare quei cambiamenti da solo. Aspetterò la fine delle vacanze del nostro amministratore di sistema e convaliderò la tua risposta se fosse corretta :-)

— Pierre

@DaveG: perché? Se provo e chown una directory come root su un mount NFSv4 ricevo esattamente lo stesso messaggio di errore dell'OP e se passo a NFSv3 ottengo il permesso negato, quindi ha qualcosa a che fare con esso e il modo in cui interagisce con gli ID utente.

— user9517

Poiché anche root viene schiacciato su NFSv3, il messaggio di errore potrebbe essere diverso ma non sarebbe ancora in grado di creare la directory come utente root.

— DaveG,

mount -t nfs -o vers=3 SERVER:PATH MOUNT_PATH

Questo ha funzionato per me.

— Shinta
fonte

Questo è davvero un problema di NFS4. Potrebbe essere necessario considerare rpc.idmapd il demone di mapping NFS4 al fine di risolvere tali problemi, soprattutto se molti utenti avranno bisogno del mapping corretto tra il client e il server NFS. Si noti che NFS3 (ad esempio in CentOS <6) non ha utilizzato un demone di mapping.

— ank
fonte