impossibile accedere a / dev / null: autorizzazione negata, sebbene crw-rw-rw- 1 root root 1, 3 set 21 12:05 / dev / null

11

Su postgres dell'utente:

$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied

Pensato sulla radice dell'utente, le autorizzazioni sono corrette:

# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null

Ho provato a ricrearlo:

# rm /dev/null && mknod -m 0666 /dev/null c 1 3

Ma il risultato è lo stesso. Sono su un VPS con debian 7 e kernel 2.6.32 su un x86_64

linux permissions

— lalebarde
fonte

18

Il problema derivava dalle autorizzazioni per / dev:

# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev

Quindi / dev non è stato accessibile dagli utenti.

# chmod a+x /dev
# chmod a+r /dev

Problema risolto.

— lalebarde
fonte

Quindi voglio sapere perché aveva quelle autorizzazioni. Potrebbe essere necessario reinstallare. Tutto in / dev è gestito dal kernel ed è strano che abbia le autorizzazioni sbagliate.

— cripto,

no, tutto in / dev non è "gestito dal kernel".

— tlund

@tlund, leggi il tuo libro del kernel preferito. "La directory / dev riflette lo stato corrente del kernel" doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/…

— cripto

@ user1048138: anch'io vorrei saperlo. Ho iniziato da un'installazione automatica di debian 7 dal mio provider VPS. Quindi ho aggiornato, aggiornato, usato solo apt-get. Più un pacchetto "a mano" con wget some_domain / some_package.deb ; dpkg -i some_package.deb; apt-get -f install. Ad un certo punto, / dev / null è stato modificato in un file standard e le autorizzazioni / dev sono state modificate. Non posso dire di più.

— lalebarde,

1

Ho avuto un problema simile e sono venuto qui cercando i sintomi, ma la soluzione non si adattava al mio caso. Quindi vorrei aggiungere un'altra possibile ragione anche se non si adatta esattamente al PO.

Nel mio caso speciale ho usato proot(un bel chrootinvolucro). Ma i permessi erano corrette su /dev/nulle /devin sé.

È capitato di essere il mount della chrootdirectory, che ho fatto tramite thunarun normale utente. Quindi, in questo caso il mount non aveva i permessi corretti.

Hai un brutto momento per trovarlo, perché non vedi queste autorizzazioni, quando guardi solo i file.

Il percorso generale della soluzione sarebbe quello di iniziare a controllare le condizioni nella posizione del problema ( /dev/null) e passare al livello successivo (s) ( /dev), quindi il mount, il file system ecc., Qualunque cosa accada dopo.

Ad ogni passaggio potresti avere diversi presupposti, ognuno con i propri livelli esterni. Ad esempio, l'utente potrebbe trovarsi in un gruppo errato, il che porta al file di configurazione del gruppo, che potrebbe avere autorizzazioni errate, ecc.

Ovviamente, devi seguire una specie di albero in generale.

— Harald
fonte

0

Non ho potuto risolvere questo da solo, quindi è quello che ho fatto:

mycommand.sh | echo -n

Il echocomando non presta attenzione all'input standard, quindi verrà scartato. Ed -nè così che una newline inutile non viene stampata su stdout.

— Mark Stewart
fonte

1

Sebbene ciò possa rispondere alla domanda, sarebbe una risposta migliore se tu potessi fornire qualche spiegazione sul perché lo faccia.

— David Post

1

Sì, ma come risponde alla domanda "impossibile accedere a / dev / null: autorizzazione negata, sebbene crw-rw-rw- 1 root root 1, 3 21 settembre 12:05 / dev / null"?

— David Post

1

Non risponde alla domanda. Ma fornisce una soluzione alternativa. A volte non esiste una risposta diretta ideale.

— Mark Stewart,

0

chmod a+rw /dev/null /dev/random /dev/urandom /dev/ptmx /dev/tty /dev/zero /dev/full /dev/fuse /dev/net/tun

questo è ciò che risolve il mio problema su VPS. Si noti che dopo aver riavviato il server è stato eseguito nuovamente questo comando

— Zore
fonte