Hide Forgot
Description of problem: smartctl doesn't seem to work when started as user, even though this user has the rw access to the device node. --- $ ls -l /dev/sda brw-rw---- 1 root disk 8, 0 Сен 26 2009 /dev/sda $ id uid=500(stas) gid=500(stas) группы=6(disk),14(uucp),50(ftp),54(lock),500(stas),505(audio) $ smartctl -a /dev/sda smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Probable ATA device behind a SAT layer Try an additional '-d ata' or '-d sat' argument. $ su -c "smartctl -a /dev/sda" smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === [then the proper output] --- Version-Release number of selected component (if applicable): smartmontools-5.38-13.fc11.x86_64 How reproducible: Always Steps to Reproduce: 1. Make sure you have the rw access to /dev/hda by adding yourself into a "disk" group 2. Run smartctl -a /dev/sda as user Actual results: Totally misleading error message. Expected results: Proper output. Additional info: Note the completely misleading error message. It suggests '-d ata' or '-d sat', which doesn't work at all.
unfortunately, SMART functions requires more than rw access to device. Used ioctl functions requires root privileges.
OK, but at least please fix the error message then. It suggests '-d ata' or '-d sat', which doesn't help at all. It was quite accidentally that I figured out about the privs. I'll keep that bug opened for now. If you feel the message is not worth fixing, then you can close it again. Btw, why the ioctls on the device require more privs than writing to it, is this intentional?
Well, the problem is ioctl returns the same return code for not enough permissions and for the situations where '-d something' should be used. That's the reason why 'Probable' and 'Try' are used in the error message. I'm not sure why ioctl requires more privs than writing. This code lays in kernel side and I would only guess. I'll look at that error message if there is any way if it can be distinguished and fix/close this bug depending on the result.
OK, so this is an SG_IO ioctl returning -EFAULT, nice... "man ioctl" doesn't even suggest the -EPERM can be returned. I think ioctl() never fails with -EPERM because the r/w access should be sufficient. And returning -EFAULT instead looks very wrong. So I wonder whether it would be good to just leave smartctl as is. ioctl() seems to behave wrongly instead, so maybe the hint from some kernel guru can help.
I've been talking with kernel guys. SQ_IO (and other ioctl) needs different privileges for different actions. For some actions you need only read perm, for some you need write perm, but for some you need CAP_SYS_RAWIO, which is available only to root (but even root does not have CAP_SYS_RAWIO capability always if this capability was removed from him by any parent process).
Would it be possible to return -EPERM then? -EFAULT looks really wrong... By the way, if you have the write perm to the drive node, like /dev/sda, then you already ignore everything on that drive, including its filesystem with permissions, partition table, and etc. So is there anything this extra priv requirement guards against?
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
This should really better be fixed. Or re-assign this to kernel?
oops, this slipped out of my circular todo list > So is there anything this extra priv > requirement guards against? with write perm. you can modify the data on that drive, but still you can't affect state of that drive From kernel pov, what I was looking for answers, this error code is somehow shared and can't fit everyone. Anyway, there is bug report filled upstream, so maybe they can make (at least) some parts working maybe. Lets wait for their opinion. http://sourceforge.net/apps/trac/smartmontools/ticket/61
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
$ smartctl -a /dev/sda smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.1.0-7.fc16.x86_64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Smartctl open device: /dev/sda failed: Permission denied