Ubuntu
udev package

/dev/null: Permission denied

Bug #69516 reported by Ordou on 2006-10-31

Affects

Status

Importance

Assigned to

Milestone

udev (Ubuntu)

Invalid

High

Scott James Remnant (Canonical)

You need to log in to change this bug's status.

Affecting:	udev (Ubuntu)
Filed here by:	Ordou
When:	2006-10-31
Assigned:	2006-11-01
Completed:	2006-11-01

Target

Distribution
Package	(Find…)
Project	(Find…)

Status	Importance
	High

Assigned to

	Me
	Scott James Remnant (Canonical) (canonical-scott)

Comment on this change (optional)

Email me about changes to this bug report

(?)

Bug Description

Binary package hint: udev

When I ssh to my server I see "permission denied messages" in my console:

[...]
-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
[...]

I [Ctrl] + [c] out of this loop and get dropped to bash. Checking then the permissions on "/dev/null", I see "crw-------" owned by root:root. After a "# /etc/init.d/udev restart" the permissions are "crw-rw-rw-". I recently upgraded from stock Dapper to Edgy, and currently running "default" Edgy (2.6.17-10-386).

udev is configured to properly set the permissions on the file (the following is in '/etc/udev/rules.d/40-permissions.rules': KERNEL=="null", MODE="0666").

I still experience this problem on every reboot.

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'

I don't know if this is related, but doing "# ls -al /dev/ | grep crw-------" gives

crw------- 1 root root 5, 1 2006-10-31 07:39 console
crw------- 1 root root 109, 0 2006-10-30 23:46 lvm
crw------- 1 root root 1, 3 2006-10-27 22:52 null
crw------- 1 root root 108, 0 2006-10-27 22:52 ppp
crw------- 1 root root 4, 1 2006-10-30 23:46 tty1
crw------- 1 root root 4, 2 2006-10-30 23:46 tty2
crw------- 1 root root 4, 3 2006-10-30 23:46 tty3
crw------- 1 root root 4, 4 2006-10-30 23:46 tty4
crw------- 1 root root 4, 5 2006-10-30 23:46 tty5
crw------- 1 root root 4, 6 2006-10-30 23:46 tty6

And "# ls-al /lib/udev/devices/ |grep crw-------" gives

crw------- 1 root root 5, 1 2006-10-27 22:52 console
crw------- 1 root root 1, 3 2006-10-27 22:52 null
crw------- 1 root root 108, 0 2006-10-27 22:52 ppp

See original description

Add tags Tag help

Ordou (khelle) wrote on 2006-10-31:

/var/log/udev Edit (269.6 KiB, text/plain)

Attachment: /var/log/udev

description:

updated

Ordou (khelle) on 2006-10-31

description:

updated

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-11-01:

Are you able to access the console of this server?

Could you provide the output of "ls /etc/rcS.d" and "ls /etc/rc2.d" for me?

Thanks

Changed in udev:
assignee:	nobody → keybuk
importance:	Undecided → Medium
status:	Unconfirmed → Needs Info
importance:	Medium → High

Ordou (khelle) wrote on 2006-11-01:

I'm still able to access the console.

"# ls /etc/rcS.d":

README S27evms
S01mountkernfs.sh S30checkfs.sh
S01readahead S35mountall.sh
S02hostname.sh S36mountall-bootclean.sh
S05keymap.sh S39readahead-desktop
S06keyboard-setup S40networking
S07linux-restricted-modules-common S40pcmcia
S08loopback S45waitnfs.sh
S10udev S46mountnfs-bootclean.sh
S11mountdevsubfs.sh S49console-setup
S13pcmciautils S50hwclock.sh
S15module-init-tools S55dns-clean
S17procps.sh S55pppd-dns
S20checkroot.sh S70screen
S22mtab.sh S70x11-common
S25brltty S80bootmisc.sh
S25mdadm-raid S85urandom
S26lvm S90console-screen.sh

"# ls /etc/rc2.d":

K81cupsys S20makedev S24mythtv-backend S99mdadm-raid
README S20mysql S25mdadm S99module-init-tools
S05vbesave S20postfix S89anacron S99networking
S10powernowd.early S20rsync S89atd S99rc.local
S10sysklogd S20samba S89cron S99rmnologin
S11klogd S20slimserver S90binfmt-support S99stop-readahead
S13gdm S20smartmontools S91apache2 S99udev
S19mysql-ndb-mgm S20ssh S98usplash S99webmin
S20backuppc S20xinetd S99evms S99x11-common
S20dbus S21mysql-ndb S99loopback
S20hddtemp S23ntp-server S99lvm

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-11-01:

Delete /etc/rc2.d/S99udev

Changed in udev:
status:	Needs Info → Rejected

Ordou (khelle) wrote on 2006-11-01:

Thanks. This solved the problem.

turncoat (uskokovic) wrote on 2007-07-22:

I have the same problem, described in bug 53040, but I don't even have /etc/rc2.d/S99udev.
I only have /etc/rcS.d/S10udev. Should it be there?

Aapo Rantalainen (aapo-rantalainen) wrote on 2007-08-15:

I had /etc/rc2.d/S50udev.
I deleted it and now it works.

(Feisty)

Dale Amon (amon) wrote on 2009-12-26:

Same problem in karmic. There are no rc files for udev. I can delete and do the mknod to correct it but it goes away on reboot. I have gone through my root .bash* files and removed umask just in case. rm'ing the file, doing the mknod with 0666 and manually restarting through init.d scripts gives me 0644; doing the same and using service udev restart leaves it as 0666. However a reboot sets it back to 0660.

Ideas?

jhthayer (jhthayer) wrote on 2010-05-24:

Similar problem in karmic. In addition to the bash-null-permission denied, I also get permission errors when kdm attempts to execute Xsession, at lines 67, 75, and 18, all points attributable to the null-permission problem. Shutting down kdm and using startx gets me in but as root only, of course. When ctrl-alt-F1 brings the command line, it is immediately followed by a couple of screenfuls of the bash: /dev/null: permission denied lines, but it stops at a command prompt, allowing the use of sudo and service kdm stop. Permissions are correct when checked, but something, PAM? doesn't process the username and password when entered in kdm, bringing a return of the login screen, information relating to this only appears in the Xsession-errors log, which also notes that the log cannot be written due to permissions, but apparently it is. I've been bashing (no pun intended) my head on this for over a month. As far as I can tell, started with either updates or with installation of udftools.