You are not logged in.
Pages: 1
Topic closed
Hi,
After update and reboot I now got -bash: /dev/null: Permission denied each time I log in... /dev/null is after reboot set to 600, I can chmod it to 666, but how can I make it persist?
Any help will be appreciated (^_^)
Thanks a lot
Last edited by p4l4cl][n (2012-06-06 14:57:07)
Offline
Can you still login as root?
Check which shell is configured for your specific user (grep <youruser> /etc/passwd). If this is set to /dev/null for whatever reason, you can use "chsh" to change it (to /bin/bash for example).
Burninate!
Offline
Oh, I propably did not say it right (I am not a native speaker...)... I CAN login as regular user, I CAN sudo chmod 666 /dev/null... But it does not persist next time I reboot..
PS: we are talking about VPS, so root login is not allowed (in sshd)
Last edited by p4l4cl][n (2012-06-06 14:10:02)
Offline
It should be set in a udev rule:
$ grep null /lib/udev/rules.d/*
/lib/udev/rules.d/50-udev-default.rules:KERNEL=="null|zero|full|random|urandom", MODE="0666"
Your rules.d dir is probably different (different distro).
Offline
brebs: thanks a lot /etc/udev/rules.d/ was empty, after I created file according to your post and rebooted, averythings seems ok now Thanks a lot again
Offline
This isn't really a fix... /dev is devtmpfs these days which means its mostly kernel managed. /dev/null is created as mode 0666, and shouldn't be touched by udev. It would be better to find out what's causing the permissions to change than to blindly override it.
Offline
I agree... but that's beyond my capabilities
Offline
I'm having the same issue as the OP, but as falconindy said, the fix used isn't really proper.
I'm using a VPS (OpenVZ), and the same happened to me after updating today (many parts of /dev lost the proper permissions, including null, zero, full, random, and urandom). I also don't have any files in /etc/udev/rules.d (although /usr/lib/udev/rules.d has a bunch of stuff).
Could someone please help point me in the right direction on finding the culprit for the change in permissions?
Also, the problem exists on two different VPS, but on a physical server I also run, the permissions are correct.
Last edited by Mister_Magotchi (2012-06-08 22:59:44)
Offline
I am on openvz too...
Offline
I talkt with falconindy, because i got the same problem so there is the fix (workaround). I know falconindy don't like override permission by udev, but maybe OpenVZ Container need this. If i had time, maybe i will look deeper in it.
Problem was upgrade from udev v182-4 to systemd-tools v184-2, because of removing the following line.
cat /etc/udev/rules.d/50-fix-permission.rules
# Thomas Lucke (Lucky) archlinux@builds.lucky.li
#
# In a OpenVZ container with enabled udev (systemd-tools), you run in some
# permission problems, because the udev rule was removed by this commit:
# http://cgit.freedesktop.org/systemd/systemd/commit/rules/50-udev-default.rules?id=378f2e074e38490103f999173bf717a5394170f8
# mem
SUBSYSTEM=="mem", KERNEL=="null|zero|full|random|urandom", MODE="0666"
btw. please post there if you get problems, because i don't follow the forum.
https://aur.archlinux.org/packages.php?ID=57949
Offline
<removed>
Last edited by rwd (2012-07-03 05:41:41)
Offline
I had the same problem that is issues with permissions of /dev/null
additionally, after I've fixed them, no terminal would start in X session
it was because I've created myself a new rule that was supposed to fix my adb permissions:
/etc/udev/rules.d/99-adb.rules
ATTRS{idVendor}=="2717", ATTRS{idProduct}=="4e42", ENV{ID_GPHOTO2}="1",
ENV{GPHOTO2_DRIVER}="proprietary", ENV{ID_MEDIA_PLAYER}="1",
MODE="0664", GROUP="plugdev"
now that I've removed this rule, everything (except for adb xD) works fine
Offline
You cannot and should not split udev rules on new lines, every new line is considered a new rule
Closing this 8 year old thread.
Offline
Pages: 1
Topic closed