/dev/null: Permission denied

Bug #63031 reported by sancho on 2006-09-29
This bug affects 4 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Scott James Remnant (Canonical)

Bug Description

Upon logging into a GNOME session from GDM, a 'gnome-terminal' opens up and displays the following in an infinite loop...

bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied

This is before the GNOME session is started and even before Metacity loads (i.e. the terminal window has no window borders). I [Ctrl] + [c] out of this loop and be dropped to bash, wherefrom I can check the permissions of "/dev/null" which are indeed set to "crw-------" and owned by root:root . Running "sudo chmod 0666 /dev/null" from the terminal window, exiting the shell, and logging back in from GDM resolves this problem until next reboot.

I have ensured that udev is configured to properly set the permissions on the file by confirming that the following is in '/etc/udev/rules.d/40-permissions.rules':

KERNEL=="null", MODE="0666"

In spite of that, I still recieve the problem on every reboot. Incidently, this has occured on two of my three Ubuntu (6.06 LTS) machines, each of different architectures; in my case, it's happening on an both an i386 and an x86_64 machine. The common thread between both is that this behavior started immediately after a particularly large system update via Synaptic (i.e. an update after a fresh install).

In the meantime, I am setting the permissions of /dev/null manually in '/etc/rc.local', but I would still like to know what is the cause of all this. This is not an acceptable long-term solution as the permissions are set too late in the 'init' process when they are placed in rc.local.

I have confirmed that others are experiencing this exact same problem at LinuxQuestions.org.

I appreciate any assistance in this matter.

Kevin Kubasik (kkubasik) wrote :

I have had the same problem, and would like to confirm.

A fix for this is to do
sudo chmod a+rw /lib/udev/devices/null

Please attach /var/log/udev

UDEV [1159593619.224292] add@/class/mem/null

Strange, an event is occuring for the /dev/null device -- which should result in the permissions being changed.

Could you run "udevtest /class/mem/null" for me?

Changed in udev:
assignee: nobody → keybuk
status: Confirmed → Needs Info
sancho (benisanag) wrote :

$ udevtest /class/mem/null
main: Usage: udevtest <devpath> <subsystem>

Did you mean perhaps "udevtest /class/mem/null /dev/null" ? Also, would you like me to run this before I manually change the perms or is it okay if it's done after they are chmod'ed?

You're running dapper?

This should definitely be fixed in edgy.

Changed in udev:
status: Needs Info → Fix Released
Peter (peter-weiss) wrote :

That's not all...

The workaround works.

But I don''t think the problem is related to udev. I installed a small testscript that runs during boot before udev starts. It sets permissions of /dev/null first to 0777, than loops in the background for while noting the /dev/null permissions and a list of processes to a file.

I saw that after udev starts the permissions change correctly to 0666, but later somewhere when hdparm starts the permissions get changed to 0600. Couldn't figure out what exactly does change the permissions, just grepping for chmod and dev/null in /etc/init.d/* doesn't show any hints.


hdparm is usually started by udev, no?

Jo Shields (directhex) wrote :

Something VERY recent has triggered this behavior to reappear. My (Edgy) laptop suffered from the problem, and I've just checked my (Edgy) desktop, where it appears /lib/udev/devices/null also has bad permissions

This has nothing to do with /lib/udev/devices/null - that should have 0600 permissions.

If you have this problem on EDGY, please open a new bug and provide the information requested (/var/log/udev and output of "udevtest /class/mem/null")

Ordou (khelle) wrote :

I'm experiencing a similar thing. When I ssh to my server I get the same permission denied messages in my console. Checking the "/dev/null", I see "crw-------" owned by root:root. After a "# /etc/init.d/udev restart" the permissions are "crw-rw-rw-". I'm running Edgy (2.6.17-10-386).

Attached is my "/var/log/udev".

"# udevtest /class/mem/null" gives:
main: looking at device '/class/mem/null' from subsystem 'mem'
udev_rules_get_name: no node name set, will use kernel name 'null'
udev_db_get_device: no db file to read /dev/.udev/db/class@mem@null: No such file or directory
udev_node_add: creating device node '/dev/null', major = '1', minor = '3', mode = '0666', uid = '0', gid = '0'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'

gunfus (gunfus) wrote :

I just did a brand new install of the 6-10.iso server image and I am having this problem. So I am running edgy already and the problem is still there. Any suggestions? or anything that I can provide to help this bug be resolved?

gunfus (gunfus) wrote :

I also noticed that if i do a "sudo vi ssh[tab-key]" I get the same error, but I only get it once.. I haven't change the permission of /dev/null, should I?

I also get this on my new Thinkpad/Edgy 6/.10, however, the behaviour is as follows:

1)With kubuntu installed out of the box, the udev service is *not* set to start at boot. This strikes me as extremely odd, but that is definitely what the KDE control center (system->services) reported. In this configuration, the laptop works fine - it boots perfectly into X, and even USB keys are detected and automounted.

2)BUT, I needed to have my own udev rule (in /etc/udev/rules.d/10-local.rules), and so I set the udev service to start automatically at boot (again, using KDE's control center).

3)Now, when the system boots, I get dumped to a login prompt, and, when I log in, I get an endless stream of "/dev/null: permission denied" messages (fortunately, these stop when I hit Ctrl-C).

4)The workaround:
    (i) /etc/init.d/udev stop ;
        #By now, /dev/null has the right permissions.

    (ii) /etc/init.d/udev start ;
        #By now, the udev symlink which I initially wanted has been created.

    (iii) /etc/init.d/kdm restart
        #And X restarts contentedly.


My system:

#udevtest /class/mem/null:

main: looking at device '/class/mem/null' from subsystem 'mem'
udev_rules_get_name: no node name set, will use kernel name 'null'
udev_db_get_device: no db file to read /dev/.udev/db/class@mem@null: No such file or directory
udev_node_add: creating device node '/dev/null', major = '1', minor = '3', mode = '0666', uid = '0', gid = '0'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'

#The relevant bit of /var/log/udev (i.e. the ones referring to "null")

UEVENT[1167754351.369243] add@/class/mem/null
UDEV [1167754351.369243] add@/class/mem/mem

UEVENT[1167754351.369249] add@/class/mem/port
UDEV [1167754351.369249] add@/class/mem/null

Hope that helps; if there are other any tests I can do, let me know.

Ordou (khelle) wrote :

See bug 69516, maybe that will help you.

Thank you. Yes, you're quite right - the root cause is trying to start udev when it is already running (although this really shouldn't have such symptoms). Perhaps the udev start script should check for udevd already running, and if so, it should just do a udevtrigger and exit.

However, in the first place, why did I add udev to rc2.d? Answer: because I looked in KDEs system services GUI, and saw that udev was NOT marked as "start at boot". This is a bug in KDE, since it doesn't read rcS.d !

EndelWar (endelwar) wrote :

I'm experiencing this bug in Feisty every time udev is updated, the chmod workaround described above fix the problem; you should packetize udev chi 666 permisiion on /lib/udev/devices/null

I did the same thing as RichardNeill ..
It just happened to me, I figured out that I needed to chmod a+w /dev/null when I tried to log in from the command prompt... I still can't log in to X

xrdb takes 100 percent of the cpu until I kill it, then I get punted back to kdm.

when will the fix come out? I see the bug says it's already release... I just installed today from the internet... so the problems are still on latest builds.

Jo Shields (directhex) wrote :

Something unknown is causing bad entries in /etc/rc*.d

Specifically, /etc/rc2.d/S*udev should not be there

The bug isn't that /dev/null has permission denied, it's that *something* is causing spurious init script entries

ah, we deturmined that to be the KDE services editor!

also, maybe there should be a script that checks rc*.d for crud like this?

Running something twice shouldn't screw it all up?!

Our initscripts should have a bit of falt tollerance built in for
stupid users like me who want an error message regarding what is
acutally broken instead of not being able to log into the box.

On 3/19/07, directhex <email address hidden> wrote:
> Something unknown is causing bad entries in /etc/rc*.d
> Specifically, /etc/rc2.d/S*udev should not be there
> The bug isn't that /dev/null has permission denied, it's that
> *something* is causing spurious init script entries
> --
> /dev/null: Permission denied
> https://launchpad.net/bugs/63031

turncoat (uskokovic) wrote :

I have this problem on ubuntu-server AND on ubuntu-desktop without KDE, so there is no KDE services editor.

Can we join this bug with #53040 and #69516?

DeeKey (privateinf) wrote :

Also bug 53040 is quite the same!

Cory Kidd (coryk) wrote :

I'm experiencing this issue with 9.04. Clean install and did a large update and cannot login to the graphical desktop now. Trying the above fix (adding the permissions line into /etc/rc.local) results in not being able to even get to the login screen. It starts to load, but never gets beyond a black screen with the cursor in the middle.

I'm running ubuntu desktop 9.04 on a VIA Epia Nano-ITX board.

willieray (williambrady) wrote :

I also am experiencing this with 9.04. Clean install ubuntu 9.04 alternate on an asus board with an amd phenom ii 920.

willieray (williambrady) wrote :

I disabled ACPI 2 in the bios and deleted /etc/rcS.d/S10UDEV and all is well. Not sure which made the difference.

willieray (williambrady) wrote :

Nevermind. Still a whole host of problems with udev missing. now it isn't called at all. Relinked S10udev. error persists

willieray (williambrady) wrote :

Workaround for Jaunty:

add the line:

chmod 666 /dev/null

to /etc/rc.local before the exit 0 line.

Aki Häkkilä (aki-hakkila) wrote :

I had this problem occur to me when just installing 9.04 from DVD iso I downloaded a couple of days earlier. This problem did not occur when installing from the CD-ROM iso downloaded today.

Pekka Panula (grimdin) wrote :

I just installed fresh 9.04 64-bit server version using ubuntu-9.04-server-amd64.iso, under Virtualbox.

After i login first time i get lots of /dev/null permission denied messages and looking its rights i can see only root can access it.

Ivaneide (ivaneidelucio) wrote :

I can confirm this in a fresh install of Jaunty 32. Also /dev/urandom has wrong permissions and login to gnome via gdm fails because of this.

Manually changing the permissions to 666 in /dev/null and /dev/urandom allows me to login in gnome but I still can't user gnome-terminal (it says there was an error in creating the child process).

My machine is an HP Pavilion dv2000 (AMD Turion 64x2).

Can I change the status or should I file another bug?

Ivaneide: have you read all the comments and checked whether they apply to you?

If none of the comments apply to you, then you cannot possibly have this bug so should open a new one.

If one or more of the comments apply to you, follow their recommendations

William Kimber (williamk) wrote :
William Kimber (williamk) wrote :

Sorry the commment got lost and only one graphic showed up. Will fix as soon as can

William Kimber (williamk) wrote :

Sorry I'll try again.

I have just got this problem. Kubuntu 8.04 - AMD64

bash: /dev/null permision denied

It started after removimg 'bootchart' with 'synaptic'. However there was left behind a 'stop-bootchart' service which didn't stop but started three 'timer 2 secs' processes owned by root. These completely filled the ' /udev ' filesystem over a couple of hours. I removed 'bootchart' because it created a large collection of files and it wasn't easy to see where the boot process was being heldup.

Gettiing 'synaptic' to *completly remove* 'bootchart' even though it was supposedly no longer installed fixed the 'stop-bootchart' and the 'timer 2 secs' problems. I now have three 'busybox timers' instead.

Deleting the 'S50udev' and 'S50udev-finish' lines from 'rc-2.d' (and 'rc-5.d' ) has stopped the '/dev/null' permisson problem However I still cannot login using graphical login screen. I get logged out again immediately. I can login as 'user' in console mode and then 'sudo startx' to get to desk top. I notice that there is nolonger a default selection in the graphical login menu, setting a default option then logging in ( and being logged out again) clears the default selection again.

I see that 'bootchart' adds code to '.initramfs' is this the main cause of the problem as my ' /dev ' directories before and after are very different. see attached comparison.png taken from 'mc'. I also discovered that despite being *completely removed*, every time the system starts it creates a new subdirectory
  ' /dev/.bootchart' complete with an executable 'bootchart' binary file!! See bootchart.png in previous comment. (sorry it cameout wrong before). Just what is going on with 'udev' and where does the '.bootchart' directory and executables come from?

psl (slansky) wrote :

It happened today on my box too. It runs Ubuntu 10.04 i386 and the box was up an running for several days without issue. I cannot unlock GNOME screensaver this morning. I tried to login from text terminal and I was able to do it but I see many errors '-'-'-bash: /dev/null permision denied'

I found that /dev/null device is just a file, not device:

$ cd /dev; ls -l null
-rw-r--r-- 1 root root 85 2011-02-22 09:23 null

I fixed the issue with command (it creates standard devices)

# cd /dev; MAKEDEV std
$ cd /dev; ls -l null
crw-rw-rw- 1 root root 1, 3 2011-02-22 09:31 null

The issue is fixed, I can unlock screensaver and login to GNOME now. The key question is, 'who deleted /dev/null device??' That was not me and it happened during night... Some application installed on my desktop has a bug that removes /dev/null device.

My guess is that it can be 'xz' or 'xzdec' or 'xz-utils' or 'epub-utils' or 'txt2pdb' or 'plucker' package; I installed these on my box yesterday.

psl (slansky) wrote :

My box runs U 10.10 i386; not Ubuntu 10.04 i386 as reported in the previous post....

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers