Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#26640 - [udev] udev, thunar, brasero and group "storage"?

Attached to Project: Arch Linux
Opened by René Herman (rene) - Wednesday, 26 October 2011, 23:12 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 06 November 2011, 23:16 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No



The upgrade to udev-174 switched optical drives from group "storage" to group "disk". Given that I don't want to give my user access to hard drives as well, I reassign them to group "optical" (of which my user is a member) through a custom udev rule:

=== /etc/udev/rules.d/81-optical.rules
# udev-174 assigns optical drives to group "disk"; reassign to group "optical"

# Permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# Permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"

Upon seeing no device files being owned by group "storage" anymore, I deleted my user from the "storage" group. I'm on an XFCE desktop and have Thunar setup to "Mount removeable drives when hotplugged" but not to "Mount removeable media when inserted". Upon inserting a CD/DVD I do get a desktop-icon, but mounting through the right-click menu at this point fails with "Not Authorized".

It used to work fine before udev-174 -- and adding my user BACK to group "storage" fixes the issue (note, both /dev/sr0 and its accompanying /dev/sg1 are in fact owned by groep "optical" after installing that custom rule, and my user is indeed a member of group "optical". nothing in /dev is owned by group "storage").

Thunar isn't the only app affected: Brasero has similar trouble:

(I only noticed the Thunar trouble after supplying that comment)

This probably means this issue belongs with udev? I also don't suppose it's purely upstream? That seemingly hardcoded "storage" group dependency might be an archlinux thing?

Or is it just me...

Additional info:
* package version(s)


Steps to reproduce:

Remove your user from the "storage" group and try to mount through the right-clock menu in Thunar or eject through Brasero.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Sunday, 06 November 2011, 23:16 GMT
Reason for closing:  Upstream
Additional comments about closing:  /dev/srX will be in the optical group again in udev-175. In the meantime, add rule given in last comment if needed.
Comment by René Herman (rene) - Thursday, 27 October 2011, 00:27 GMT
It just now occurred to me that it seems relatively likely that "udisks" is involved, since if I remember correctly I once installed that to have things Just Work (TM). Perhaps now it Just Broke (C).

I have udisks-1.0.4-1 installed.
Comment by Jan de Groot (JGC) - Thursday, 27 October 2011, 06:27 GMT
I guess you installed some custom policykit rules that allow the storage group to mount these things. Vanilla configuration only allows sessions registered with ConsoleKit to access these devices.
Comment by René Herman (rene) - Thursday, 27 October 2011, 12:30 GMT
Mmm. I haven't personally installed any such rule, but I see I do have a file /etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks.pkla which mentions the storage group:

[Local Users]
#Identity=unix-user: your_username

This file is installed by thunar:

# pkgfile /etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks.pkla

I just now reinstalled thunar to make sure I never edited it, and yes, it's vanilla Thunar. I'm not sure how this stuff is supposed to work but this feels a bit peculiar?

(Yes, I do start my session through ck-launch-session. As advised at, in /etc/slim.conf I have

login_cmd exec ck-launch-session /bin/bash -login ~/.xinitrc %session

combined with an otherwise plain archlinux ~rene/.xinitrc that [starts dbus-launch from /etc/X11/xinit/xinitrc.d/30-dbus and] execs xfce4-session.)

If this means it's a Thunar issue, is it possible to change that in the topic and transfer this report to Thunar? The Thunar arch wiki page does mention adding the user to the storage group in the context of automounting but at least I find it rather counter-intuitive that I still need to do so after having no device files belong to that group anymore...
Comment by René Herman (rene) - Friday, 28 October 2011, 15:06 GMT
Upon this being assigned...

I guess the correct question might be "why did the udev-174 upgrade stop handling group 'storage'?". It seems that at least Thunar by default needs the group (if only due to it wanting users to be part of it; it supposedly wants this due to the fact that it USED to be necesary for them to be part of this group back when it was also the way to provide them access to the devices themselves).
Comment by Tom Gundersen (tomegun) - Friday, 28 October 2011, 15:40 GMT
I'm a bit puzzled. I'll have to get back to this report later, but for now, a few comments:

optical drives (at least non-ide drives, which are the only ones as of linux 3.1) should be in the optical group by default, and not in disks/storage. It is true that some things (usb sticks) that used to be in storage are now in disks, but cdroms should not be one of them.

If everything works the way it should when your user is in the storage group, even if the device is in the optical group, then this is not a udev problem. You are still free to be in the storage group even with udev-174, it just does not assign any devices to that group.

It sounds a bit odd for brasero/thunar to check for this group in their PK rules. Maybe looking for "optical" would make more sense, or just rely on the local user getting access through CK?
Comment by Dave Reisner (falconindy) - Friday, 28 October 2011, 17:03 GMT
..and what other rules might you have in /etc/udev/rules.d?
Comment by René Herman (rene) - Friday, 28 October 2011, 19:15 GMT
@ Dave:

None. I used to have no custom rules at all, but after the upgrade to udev-174 my SATA DVD-RW drive (/dev/sr0) was now owned by root.disk.

Given that user "rene" wasn't a member of group "disk", this resulted in an inability for "rene" to burn CD/DVDs and upon investigating I encountered more people with the same problem, for example at:

(I took my custom udev rule from comment #3 there). If you are saying that my DVD drive SHOULD have been root.optical without any custom rule installed, then I guess that's the part of the problem that's directly related to udev: it is not. Not for me, not for at least a few others -- and I was up to now assuming that it was for no one.

Yes, the "storage" group thing is relatively decoupled. After installing the custom rule, and without my user a member of group "storage", both Thunar and Brasero can do SOME things with my DVD drive again. For example, Thunar can eject an automounted CD/DVD (but can not manually mount it) and Brasero can burn a CD/DVD (but cannot eject it at the end automatically, nor through its menu).

The Brasero bit is perhaps best to forget, since Thunar may be interfering there, so let's just say that without my user a member of group "storage", Thunar cannot mount. In so far that this is a problem (I find it to be unexpected, opague behaviour, without any device node owned by group "storage") it seems to foremost be a Thunar problem, not so much udev. In mere practical terms, adding the user back to group "storage" solves/hides the issue...

However, it does seem to show that group "storage" is being assumed by programs, Thunar at least, on the system and this beckons the question of why the upgrade to udev-174 stopped assignment of my drive to the storage group (independent of whether or not it should have been to "optical" instead of to "disk"). The upgrade commented that it did such but did not explain why. If a "storage" group dependency such as the Thunar one is not simply to be considered a Thunar bug, I believe that this may be an argument as to whether/why udev should restore the former behaviour of assigning these drives to group "storage", at least until all such dependencies have been flushed from the rest of the system?

Note, may. I'm the type of "old time user" who lost track at the udev/consolekit/policykit/dbus stage. I have little oversight how everything is INTENDED to work.
Comment by René Herman (rene) - Friday, 28 October 2011, 19:45 GMT
... adding to/clarifying that last part a bit:

As in, back when the actual device nodes where owned by group "storage", I found it to be perfectly sensible that I needed to add my user to that group in order to give Thunar/Brasero access to it, but after udev-174 I find it to be fairly nonsensible that I now need to add my user to TWO groups; one the group that owns the device node, and two group "storage". Moreover, while having to do that indeed feels more like a Thunar problem than a udev one, I'm still wondering why udev changed it in the first place and if it should not perhaps be restored until oddities such as the Thunar one are purged from the system.
Comment by Tom Gundersen (tomegun) - Sunday, 30 October 2011, 14:09 GMT
There are two separate issues that are being confused here. Could you open two separate reports?

One is: cdrom is in the disk group rather than the optical group. What we need here is the output of "udevadm info -a -n /dev/sr0" (or whatever your cdrom node is).

The other is: Thunar can not mount cdrom. I'm not sure exactly what is going on here, but the policykit file (which is added by Arch, and not upstream) seems wrong. CK should give you permission to deal with the cdrom, but the above bug probably has to be solved first.
Comment by Dave Reisner (falconindy) - Sunday, 30 October 2011, 15:50 GMT
I'll chime in on the udevadm output... This device is grouped to disk, likely because it shows up as part of the block subsystem.
Comment by René Herman (rene) - Sunday, 30 October 2011, 18:41 GMT
As requested, attached the udevadm info output.

However, as to opening a separate report for the Thunar problem/oddity, that does sort of require me knowing what the nature of said problem is.

Before this thread happened, I wasn't even aware that the drive being assigned to "disk" rather than "optical" wasn't intentional, and had as mentioned already "fixed" that part locally through a custom udev rule. It's the Thunar/Brasero trouble that is in fact central to this report and I am trying to ascertain the reason why that problem surfaced in the first place. That is, like was asked a few times now, why udev changed the assignment to group "storage".

Only after an arch linux udev person says "we did that because <foo> and yes, we're certainly going to keep it that way" am I able to report to the Thunar maintainers what the nature of THEIR problem is (or if they even have a problem). That is, if that Thunar PK rule needs to just dissappear, be changed, be replaced by something else, be ...
Comment by Tom Gundersen (tomegun) - Sunday, 30 October 2011, 20:13 GMT

Looks like I got the wrong end of the stick with regards to group membership of /dev/sr0 (a good example why these things should be maintained upstream ;-) ).

I haven't been able to verify this with upstream yet, but I think the intention is that /dev/srX is in "disk" and the corresponding /dev/sgY is in "optical".

Could you paste the output of "ls -lah /dev", and of "lsmod" with old and new udev, without any custom rules installed?
Comment by René Herman (rene) - Sunday, 30 October 2011, 22:01 GMT
If you'll settle for the output from within a self-compiled 3.1.0 kernel. Downgrading to udev-173-3 requires downgrading to mkinitcpio-0.7.4-1 and after regenerating the initramfs (with just mkinitcpio -p linux) the current default arch kernel (3.0.7) won't boot. That same kernel works fine with current mkinitcpio and udev so it's some involved problem again that I'm not going to bother myself with currently.

Attached are "ls -lah /dev" on 3.1.0 with udev-173-3 and again with udev-174-1, and after cutting out the date column, here's the difference. /dev/sr0 moved from group "optical" to group "disk". Not sure why it's not in "storage" instead with 173-3 in this listing (no custom rules installed).

EDIT: Attached the .diff as well in stead of pasting it in due to the variable-width font here. Very unhelpful.

Just before posting I see I forgot to get the lsmod results. Will get and add them to the next comment.
Comment by René Herman (rene) - Sunday, 30 October 2011, 22:12 GMT
My lsmod is quite uneventful and the same with both versions of udev.
Comment by Tom Gundersen (tomegun) - Sunday, 30 October 2011, 23:13 GMT
@René: thank yo ufor your feedback. This was very useful.

Just to clarify one last thing: am I right in thinking that if you are _not_ in the "storage" group, thunar fails with both udev versions, and if you _are_ in the "storage" group it succeeds with both versions?
Comment by René Herman (rene) - Sunday, 30 October 2011, 23:34 GMT
Did some additional testing due to your above mentioned expectation. Yes. the current situation is as you said you expect the upstream intention is. /dev/sr0 is root.disk and the accompanying /dev/sg1 is root.optical.

Limiting to Brasero since it's behaves most transparently:

Without my user a member of group "disk", and with or without the Thunar pollkit file (see #3) in place and with or without my user a member of group "storage", Brasero in this situation bombs out. No burning, no blanking, no ejecting.

If your above mentioned expectation that /dev/sr0 should indeed be in group "disk" is correct, it would seem that at least Brasero will just not work unless users add themselves to the "disk" group (not a good idea), reassign /dev/sr0 to group "storage" (didn't arch used to do that for them?) or reassign /dev/sr0 to, for example, group "optical" but still make sure they are also a member of "storage" to also have ejecting (and Thunar) work.

Yech. Things used to work relatively transparently through the storage group. Again, why did that stop?
Comment by René Herman (rene) - Sunday, 30 October 2011, 23:45 GMT

If I'm not in group "storage" with udev-173, it's a mixed bag. It has /dev/sr0 in "optical" and I am also a member of group "optical" and can therefore do SOME things. Thunar for example can eject (but not manually mount), and Brasero can burn (but not eject).

If I'm not in group "storage" with udev-174, and not in "disk", I basically cannot do anything.

If I'm not in group "storage" with udev-174, but am in "disk" or have reassigned /dev/sr0 to some other group that I am a member of (ie, "optical") we're back at the 173 behavior.

Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0 (although, as this report started, I find having to also be in group "storage" if that is not in fact that latter group unexpected, opaque behavior).
Comment by Tom Gundersen (tomegun) - Sunday, 30 October 2011, 23:52 GMT
@René: Things are clearly not working the way they should on several levels, so thanks for sticking with this. I think I'll have to take this to the udev people to figure out what is the expected group of /dev/sr0 and why.

Another point: mounting, ejecting, etc. should when everything is fixed work even if your user is not in any groups at all (ConsoleKit should give the correct permissions). That said, I'd still like to sort the group ownership out.
Comment by René Herman (rene) - Sunday, 30 October 2011, 23:59 GMT
Okay, I'll hang around for further information. I expect it could also be instructive to ask the archlinux thunar maintainer why they at some point added that polkit file. They have perhaps already inquired upstream upon seeing some things not working.
Comment by René Herman (rene) - Monday, 31 October 2011, 00:24 GMT
Sorry for spamming this report but I just noticed that I should adjust the last bit of the reply above. Instead of:

"Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0"

I should clearly say

"Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0 AND in the group that owns the accompanying /dev/sgN".

So lovely...
Comment by Tom Gundersen (tomegun) - Wednesday, 02 November 2011, 13:26 GMT
@René: are you able to reproduce this problem if you use a desktop manager (preferably gdm, as that is known to work well).
Comment by René Herman (rene) - Wednesday, 02 November 2011, 13:51 GMT
Hang on, Ionut Biru is preceding along those lines as well in the precursor to this report...
Comment by René Herman (rene) - Wednesday, 02 November 2011, 13:56 GMT
slim seems to interfering in non-helpful ways. I'll get rid of it but this will have to wait a bit until I have a bit more time.
Comment by Andreas Radke (AndyRTR) - Thursday, 03 November 2011, 07:08 GMT
[root@workstation64 andyrtr]# ls -lha /dev/sr0
brw-rw---- 1 root disk 11, 0 2. Nov 23:12 /dev/sr0

I don't use any display manager. I start my Awesome and Xfce desktop with exec ck-launch-session foo.

root:disk permission seems to be a bug in udev to me. The same happens with LTS kernel and udev-compat.
Comment by René Herman (rene) - Thursday, 03 November 2011, 14:03 GMT
@ Andreas: By now I believe I've been told that root.disk (for /dev/sr0; root.optical for /dev/sg*) is not be considered a bug, and that if only I'd have a correct consolekit setup, Brasero would still allow me to burn CDs without being a member of group disk.

Which it doesn't do currently. Also, the current upgrade to xfce4-session 4.8.2-2 just now stopped my ability to reboot my computer from within XFCE since now group "power" ALSO doesn't make any difference anymore: it deleted the other .pkla files in my /etc. Which is, I'm sure, a good thing. It's just that nothing works anymore, but hey, I shouldn't be using slim. It's broken. Now, when I just now tried to quickly replace it by lxdm, that didn't work either since lxdm doesn't listen to a "nullok" setting in its PAM file; but I'm sure that's a good thing as well. I mean, no one should be using null passwords, right? Installing GDM drags in basically all of GNOME which seems to basically be the answer on current Linux systems. Install GNOME and conform or be damned.

Sorry, as indicated, replacing slim with something else to test will have to wait a bit again. I now have to reboot to Windows XP again to get some actual work done involving 3D apps that lock up intel-dri on Linux. Wonder if Ctrl-Alt-Del works.

But I still love thinking of myself as someone who thinks Linux is actually useful and not just one gigantic waste of my time. I'm l33t like that.
Comment by Tom Gundersen (tomegun) - Thursday, 03 November 2011, 14:22 GMT
@René: just to clarify, what you say about group ownership is my guess, but I have not had it confirmed (and I don't use my dvd drive so have not been able to test this much myself). Also, I hope we can make all the DM's work in the end, but testing with GDM would be helpful. If that does not work, we know we have a big problem, if it does work then the problem is probably in the configuration of slim/lxde (which should be simpler to fix).

What we should aim for is that everything (poweroff/mounting of drives/...) should work even if you are not the member of any group. If it does not, something is wrong. As I said, the best would be to compare with GDM first to figure out where to start.
Comment by René Herman (rene) - Thursday, 03 November 2011, 14:48 GMT
In the coming days the arch bugzilla will see a number of reports about reboot and shutdown not working from within XFCE anymore so those will also be helpful in determining if it's only non-gdm users. Sorry, really really have to be gone, for about a week.
Comment by ctxfi-user (ctxfi-user) - Saturday, 05 November 2011, 09:41 GMT
@René: Maybe the ConsoleKit/PolKit session is broken. Does ck-list-sessions list your session local? ConsoleKit/PolKit needs a registered session (done with /bin/login). For instance you could kill your X session, login on a VT, then startx. Against some other mistakes your .xinitrc should only contain exec ck-launch-session startxfce4. (dbus-launch is done with startxfce4.)
Comment by Tom Gundersen (tomegun) - Sunday, 06 November 2011, 22:18 GMT
Just a small update: assigning /dev/srX to optical.root was explicitly removed upstream in 174, still waiting to figure out if this was intentional, and if so, why (and why not also /dev/sgX is treated the same).
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 06 November 2011, 23:05 GMT
/dev/sr0 should have an ACL if you are logged via ck. (ls -l shows a "+" in mode, and getfacl /dev/sr0, must list your user with mode "rw-")
Comment by Tom Gundersen (tomegun) - Sunday, 06 November 2011, 23:15 GMT
djgera is right that ACL's should take care of this.

However, it is also the case that /dev/srX should be in 'optical' after all. This will be fixed in udev-175. If you want to fix it before that I suggest adding a rule file '51-tmp-optical-fix.rules' to /etc/udev/rules.d/ containing the line

SUBSYSTEM=="block", KERNEL=="sr[0-9]*". GROUP="optical"

Remember to remove it when the next udev version is out though.

As to you thunar/brasero problems, they should be sorted out by making sure consolekit is assigning ACL's properly. I will close this bug as 'upstream' (referring to the udev permissions).