Description of problem: Not sure if udev is the right place for this, but it seems like the best fit. With Fedora Core 3 and 4 (with 2.6 kernel and udev support), /dev/root comes up with mode 0600, owner "root" and group "root". This breaks backup routines, like amanda, which rely on group-read permission for the "disk" group. All the other devices corresponding to mounted partitions seem to have the correct permissions and group assignment, but not /dev/root, for some reason. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. set up the FC3 or FC4 host as an amanda client 2. set up your amanda server's disklist to include client host's "/" file system 3. run "amcheck" on amanda server Actual results: ERROR: fc4client: [could not access /dev/root (/): Permission denied] Expected results: The "amcheck" and "amdump" commands should work correctly, i.e. the amanda client should have sufficient permissions to access /dev/root. Additional info: By manually running "chmod 640 /dev/root; chgrp disk /dev/root", I can fix the problem temporarily. However, these settings are lost on the next reboot. I'm not sure what the best way to fix this permanently would be, in keeping with the udev way of doing things...
This seems to be a broader issue than just /dev/root. Other devices in the "disk" group are also an issue. Amanda chokes because /dev/nst0 is 640, should be 660. VMware raw disk access fails because /dev/hda* is 640, should be 660.
I also have this problem. And I followed the rules at http://fedora.redhat.com/docs/udev/ by creating /etc/udev/permissions.d/51-new.permissions (same pugo has 50-udev.permissions) containing root:root:disk:0640 But after reboot nothing happens.
Creating a file called /etc/udev/rules.d/60-local.rules that contains the following lines seems to solve the problem, at least as near as I can tell... KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="0", PROGRAM=="/etc/udev/scripts/ide-media.sh %k", RESULT=="disk", GROUP=="disk", MODE=="0660" KERNEL=="hd[a-z]*", BUS=="ide", GROUP=="disk", MODE=="0660" there's probably a more "robust" solution, but it works for me, so far... Bruce
standard is 0640 ... see $ fgrep STORAGE /etc/makedev.d/00macros =STORAGE 640 root disk I will fix /dev/root, btw.
...and yet in RHEL4 (something similar must have been in FC3): # grep hd /etc/udev/permissions.d/50-udev.permissions hd*:root:disk:0660 # grep st /etc/udev/permissions.d/50-udev.permissions sndstat:root:root:0660 st*:root:disk:0660 nst*:root:disk:0660 Will fixing /dev/root solve amanda's problem if /dev/nst* (or whatever tape device) isn't also changed? Should I file a bug against amanda and ask for overrides in /etc/udev/permissions for tape devices?
should be fixed in current erratum
I've updgraded to udev-071-0.FC4.2, and the problem I originally reported with /dev/root still exists after a reboot. This update adds the following line... KERNEL=="root", GROUP="disk", MODE="0640" ... to /etc/udev/rules.d/50-udev.rules, which is something I had already tried on my own. Not sure why that doesn't work, though... As for Matthew Saltzman's question about /dev/nst*, those devices would only be used by amanda-server if you happen to be backing up to a tape drive. This may still be an issue for some, but my problem with /dev/root affects amanda-client whenever you try to backup the root partition using the pathname "/" instead of the actual device name. (When you're backing up many client systems, each having a potentially different physical device name for the root file system, using the pathname "/" makes things much more manageable!) As for where the bug should be filed, I think the /dev/root problem belongs in udev, rather than amanda-client (since it could potentially affect other software too). The problem with /dev/nst* is also potentially not limited to amanda-server - it's really a question of how those devices are likely to be used, and by whom.
$ find /sys/ -name root | wc -l 0 /dev/root is created with MAKEDEV
oops, wrong.. hmm.. it's already there from initrd
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
There are still /dev permission-related issues in FC6. The tape devices are now 0660 owner root, group disk, which seems OK. The disk devices are 0640 owner root, group disk, which is still an issue for VMware raw disks. /dev/root is still 0600, owner root, group root, which was the original complaint. Comments #4 and #6 promised a fix for this, but it doesn't appear to have happened. On the other hand, Amanda isn't complaining in my case. Also, my scanner, /dev/sg0 is 0600, owner root, group root, which chokes xsane. Running xsane as normal user results in no devices found. Running as root results in a warning about running as root.
I'm seeing exactly the same problem under both FC5 and FC6 as with previous distributions. Permissions on /dev/root have not changed, as Matthew already stated, and I still get the same errors from Amanda's "amcheck" program, due to this permission problem. I've therefore updated the target version to fc6.
Still appears to be present in Fedora 7 test 4. True even after updating to most recent udev using yum (udev-106-4.fc7) and rebooting.
It is also a problem in FC8. /dev/root has these permissions afetr reboot brw------- 1 root root 8, 2 2008-02-20 17:19 /dev/root When it should have the permissions brw-r----- 1 root disk 8, 2 2008-02-20 17:19 /dev/root However the udev permssion files have changed an no /dev/root rules appear to exist any more, NOT that they worked in previous versions of various linux distros. Getting /dev/root is vital to ensuring successfull backup of machines
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still a problem under Fedora 9... brw------- 1 root root 8, 2 2008-05-22 13:23 /dev/root
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still a problem under Fedora 11... brw-------. 1 root root 8, 2 2009-07-23 11:23 /dev/root Is anyone ever going to fix this simple bug, or should I just give up on attempting to reopen it for future Fedora releases?