ne peut pas accéder à / dev / null: autorisation refusée, bien que crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 / dev / null

11

Sur les postgres des utilisateurs:

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

Pensé à la racine utilisateur, les autorisations sont correctes:

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

J'ai essayé de le recréer:

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

Mais le résultat est le même. Je suis sur un VPS avec un debian 7 et un noyau 2.6.32 sur un x86_64

linux permissions

— lalebarde
source

18

Le problème venait des autorisations de / dev:

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

Donc / dev n'était pas accessible aux utilisateurs.

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

Résolu le problème.

— lalebarde
source

Je veux donc savoir pourquoi il avait ces autorisations. Vous voudrez peut-être réinstaller. Tout dans / dev est géré par le noyau et il est étrange qu'il ait les mauvaises autorisations.

— cripto

non, tout dans / dev n'est pas "géré par le noyau".

— tlund

@tlund veuillez consulter votre livre de noyau préféré. "Le répertoire / dev reflète l'état actuel du noyau" doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/…

— cripto

@ user1048138: J'aimerais aussi savoir. Je suis parti d'une configuration Debian 7 automatique de mon fournisseur VPS. Ensuite, j'ai mis à jour, mis à niveau, utilisé uniquement apt-get. Plus un paquet à la main avec wget some_domain / some_package.deb ; dpkg -i some_package.deb; installer apt-get -f. À un moment donné, / dev / null a été remplacé par un fichier standard et les autorisations / dev ont été modifiées. Je ne peux pas en dire plus.

— lalebarde

1

J'ai eu un problème similaire et je suis venu ici en recherchant les symptômes, mais la solution ne convenait pas à mon cas. J'aimerais donc ajouter une autre raison possible, même si elle ne correspond pas exactement à l'OP.

Dans mon cas spécial, j'ai utilisé proot(un joli chrootemballage). Mais les autorisations étaient correctes sur lui /dev/null- /devmême.

C'était le montage du chrootrépertoire, que j'ai fait via en thunartant qu'utilisateur normal. Donc, dans ce cas, le montage ne disposait pas des autorisations appropriées.

Vous avez du mal à trouver cela, car vous ne voyez pas ces autorisations, lorsque vous ne regardez que les fichiers.

Le chemin de solution général serait de commencer à vérifier les conditions à l'emplacement du problème ( /dev/null) et de passer au (x) niveau (x) suivant (s /dev), puis au montage, au système de fichiers, etc., tout ce qui vient ensuite.

À chaque étape, vous pouvez avoir plusieurs conditions préalables, chacune ayant ses propres niveaux externes. Par exemple, l'utilisateur pourrait être dans un mauvais groupe, ce qui conduit au fichier de configuration du groupe, qui pourrait avoir de mauvaises autorisations, etc.

De toute évidence, vous devez suivre une sorte d'arbre en général.

— Harald
source

0

Je n'ai pas pu résoudre celui-ci moi-même, alors c'est ce que j'ai fait:

mycommand.sh | echo -n

La echocommande ne fait pas attention à l'entrée standard, elle sera donc ignorée. Et -nc'est ainsi qu'une nouvelle ligne inutile n'est pas imprimée sur stdout.

— Mark Stewart
source

1

Bien que cela puisse répondre à la question, ce serait une meilleure réponse si vous pouviez expliquer pourquoi .

— DavidPostill

1

Oui, mais comment répond-il à la question "ne peut pas accéder à / dev / null: autorisation refusée, bien que crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 / dev / null"?

— DavidPostill

1

Cela ne répond pas à la question. Mais il fournit une solution de contournement. Parfois, il n'y a pas de réponse directe idéale.

— 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

c'est ce qui résout mon problème sur VPS. Veuillez noter qu'après avoir redémarré votre serveur - vous avez exécuté à nouveau cette commande

— zore
source