13

On user postgres:

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

Thought on user root, permissions are correct:

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

I have tried to re-create it:

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

But the result is the same. I am on a VPS with a debian 7 and kernel 2.6.32 on a x86_64

Improve this question
0

4 Answers 4

Reset to default
20

The problem came from the permissions to /dev:

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

So /dev was not accessible by users.

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

Solved the problem.

Improve this answer
4
  • So i want to know why it had those permissions. You may want to reinstall. Everything in /dev is kernel managed and its odd for it to have the wrong permissions.
    – cripto
    Commented Sep 21, 2014 at 18:36
  • no, everything in /dev is not "kernel managed".
    – tlund
    Commented Sep 21, 2014 at 21:11
  • @tlund please review your favorite kernel book. " /dev directory reflects the current state of the kernel" doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/…
    – cripto
    Commented Sep 22, 2014 at 3:13
  • @user1048138 : I would like to know too. I started from an automatic debian 7 setup from my VPS provider. Then I updated, upgraded, used only apt-get. Plus one package by "hand" with wget some_domain/some_package.deb; dpkg -i some_package.deb; apt-get -f install. At one point, /dev/null was changed to a standard file, and /dev permissions changed. I cannot tell more.
    – lalebarde
    Commented Sep 22, 2014 at 7:57
1

I couldn't solve this one myself, so this is what I did:

mycommand.sh | echo -n

The echo command does not pay attention to standard input, so it will be discarded. And the -n is so that a useless newline is not printed to stdout.

Improve this answer
3
  • 1
    While this may answer the question, it would be a better answer if you could provide some explanation why it does so.
    – DavidPostill ♦
    Commented Feb 12, 2015 at 6:36
  • 1
    Yes, but how does it answer the question "cannot access /dev/null: Permission denied, although crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null"?
    – DavidPostill ♦
    Commented Feb 12, 2015 at 8:10
  • 1
    It does not answer the question. But it provides a workaround. Sometimes there isn't an ideal direct answer.
    – Mark Stewart
    Commented Feb 12, 2015 at 19:52
1

I had a similar problem, and came here by searching for the symptoms, but the solution didn't fit my case. So I'd like to add another possible reason even if it's not exactly fitting the OP.

In my special case I used proot (a nice chroot wrapper). But the permissions were correct on /dev/null and /dev itself.

It happened to be the mount of the chroot directory, which I did via thunar as a normal user. So, in this case the mount did not have the correct permissions.

You have a bad time to find this, because you don't see these permissions, when only looking at the files.

The general solution path would be to start checking conditions at the problem location (/dev/null) and step out to the next level(s) (/dev), then the mount, the file system etc., whatever comes next.

On each step you may have several preconditions, each having it's own outer levels. E.g. the user could be in a wrong group, which leads to the group configuration file, which could have wrong permissions etc.

Obviously, you have to follow a kind of tree in general.

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

this is what solve my problem on VPS. Please notice, that after you reboot your server - you have run this command again

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .