La radice non può essere modificata?

Nel mio dipartimento abbiamo un piccolo file server con CentOS e samba. Ho l'accesso come root per poter eseguire alcuni interventi di manutenzione di base.

Oggi stavo realizzando alcune cartelle di sola lettura, quindi sono andato avanti e ho fatto un chmod -R -w some-folder/, ma per alcuni file ho ottenuto la risposta:

chmod: ./somefile.pdf: le nuove autorizzazioni sono r-xrwxr-x, non r-xr-xr-x

Dopo aver aggiunto -vnon ricevo molte informazioni:

modalità di `./somefile.pdf 'mantenuta come 0575 (r-xrwxr-x)

Ho provato quanto segue solo per assicurarmi:

# touch test-file
# chmod -v -R -w .
mode of `./somefile.pdf' retained as 0575 (r-xrwxr-x)
chmod: ./somefile.pdf: new permissions are r-xrwxr-x, not r-xr-xr-x
mode of `./test-file' changed to 0444 (r--r--r--)

Non riesco a pensare a nessuna buona ragione per cui root non sia in grado di fare un chmod?

Alcuni bocconcini:

Il filesystem non è di sola lettura (solo alcuni file si sono rifiutati di essere scambiati).
Ho eseguito i comandi chmod come root ma senza alcun effetto.
La partizione in cui risiedono i file è ext4.

AGGIORNAMENTI : questo è l'output per lsattril file e la cartella contenente:

# lsattr somefile.pdf
-------------e- somefile.pdf
# lsattr ..
-------------e- ../myfolder

Non è presente setuid presente ( ls -la):

dr-xr-xr-x  2 userxyz abc   4096 May 30 09:29 .
dr-xr-xr-x 17 userxyz abc   4096 Sep 19  2013 ..
-r-xrwxr-x  1 userxyz abc 275150 Aug  6  2013 somefile.pdf

chmod

— Roflo
fonte

Stai accedendo a questi file da remoto?

— Luciano Andress Martini,

Qual è l'output di lsattrsu quegli stessi file e la directory sopra di esso?

— Ryder,

Secondo le fonti, hai una modalità prevista ingenua . Dopo aver abbandonato di più, penso che la causa sia l' -wopzione, che non è quello che ti aspetti. Dovresti dare g-wo ugo-w(in base alle tue esigenze).

Senza fornire un target esplicito (a, o, g, u) potrebbero essere forniti alcuni risultati imprevisti, in base al valore umask. Penso che questo messaggio extra sia stato fatto a causa di tali cambiamenti inaspettati.

Modifica: fonti in http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/chmod.c#n301

Tratto dalla cache di Google, un commento in quel codice che non c'è più:

/ * Se vero, diagnosticare sorprese da abusi ingenui come "chmod -r file". POSIX consente la diagnostica qui, come dovrebbe usare il codice portatile. "chmod - -r file" * /

— Giacomo Catenazzi
fonte

Sì, era così. L'ho cambiato in ugo-we non si lamenta più. Aspetterò un po 'di tempo prima di accettare per cortesia i potenziali risponditori.

— Roflo,

E accolgo con favore le modifiche o le risposte migliori, perché ancora non capisco perché chmod funzioni in questo strano modo.

— Giacomo Catenazzi,

man chmod: "Una combinazione delle lettere ugoa controlla quale accesso degli utenti al file verrà modificato [...] Se nessuna di queste viene fornita, l'effetto è come se fosse data (a), ma i bit impostati in le umask non sono interessate. " Quindi puoi fare cose come il file chmod + w e dare accesso in scrittura solo a quelli che lo otterrebbero quando crei un nuovo file. Il comportamento negativo sembra comunque un po 'confuso, quindi l'avvertimento sembra una buona idea.

— ilkkachu,