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 | | | | |

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 | | | | |
  • 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 Sep 21 '14 at 18:36
  • no, everything in /dev is not "kernel managed". – tlund Sep 21 '14 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 Sep 22 '14 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 Sep 22 '14 at 7:57

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 | | | | |

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 | | | | |
  • 1
    While this may answer the question, it would be a better answer if you could provide some explanation why it does so. – DavidPostill Feb 12 '15 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 Feb 12 '15 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 Feb 12 '15 at 19:52
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 | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.