[SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

UO14 · 2025-10-21 13:28:28

UPDATE:

[SOLVED]
https://github.com/systemd/systemd/issues/39426
now has commits with pull request pending so I think we can take that as bug confirmed.
From here on follow there for further.

---
(background I'm not at all significantly experienced with linux, I'm trying to grant the mpd dropped privileges services user access to cd-rom however, NB: this is just for background, this thread does not really concern that end in particular)

/dev/sr0 being an optical drive device (blu-ray/dvd/cd) - the following concerns behavior before logging into any GUI, i.e. tty

- I have noticed that upon reboot, and without any disk inserted, the group of /dev/sr0 is 'optical'.

getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: optical
user::rw-
group::rw-
mask::rw-
other::---

- upon inserting a disk the group is set to 'disk'

getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: disk
user::rw-
group::rw-
mask::rw-
other::---

I have had someone else test this with their Arch, and they see the same behavior, including with data discs (as opposed to audio)

This seems to be possibly wrong for a number of reasons.

To my mind it is not in agreement with the following.
https://wiki.archlinux.org/title/Users_ … emd_groups

disk /dev/sd[a-zA-Z]*[1-9]*, /dev/nvme[0-9]*p[1-9]*, /dev/mmcblk[0-9]*p[1-9]* Access to block devices not affected by other groups such as optical, floppy, and storage.
...
optical /dev/sr[0-9], /dev/sg[0-9] Access to optical devices such as CD and DVD drives.

- It is not useful to treat an optical drive as a block device in 'preference' to an optical device (optical > disk), furthermore, what now is the use of 'optical' at all?
- in particular it seems to me that adding users of any kind to 'disk' would be very undesirable.
- while there are other mechanism these do not apply for needs where the user needing access does not 'logon' , such as my background use case (ie it seems to me that uaccess tag's are not an option)
(- its a bit off topic as its specific to my case but it seems to me that udisks with its need for wrappers seems like a gross over-complication for something this basic, that said I don't think I understand udisks, so thats just an impression).
----
To anticipate someone might ask this is the udev logging.

Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Sending message: {"parameters":{}}
Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Changing state processing-method → processed-method
Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Changing state processed-method → idle-server
Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Changing state idle-server → pending-disconnect
Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Changing state pending-disconnect → processing-disconnect
Oct 21 10:38:49 archetype systemd-udevd[334]: varlink-17-17: Changing state processing-disconnect → disconnected
Oct 21 10:39:26 archetype systemd-udevd[334]: sr0: Device is queued (SEQNUM=4036, ACTION=change)
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-6rd-tunnel.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-auto-link-local.network.example' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-container-host0-tun.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-container-host0.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-container-vb.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-container-ve.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-container-vz.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-namespace-ns-tun.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-namespace-ns.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-vm-vt.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-wifi-adhoc.network' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-wifi-ap.network.example' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/80-wifi-station.network.example' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/systemd/network/89-ethernet.network.example' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: Skipping file '/usr/lib/udev/rules.d/README' with unexpected suffix.
Oct 21 10:39:26 archetype systemd-udevd[334]: sr0: Device ready for processing (SEQNUM=4036, ACTION=change)
Oct 21 10:39:26 archetype systemd-udevd[334]: Successfully forked off '(udev-worker)' as PID 3142.
Oct 21 10:39:26 archetype systemd-udevd[334]: sr0: Worker [3142] is forked for processing SEQNUM=4036.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Processing device (SEQNUM=4036, ACTION=change)
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Successfully took flock(LOCK_SH) for /dev/sr0, it will be released after the event has been processed.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: sd-device: Created database file '/run/udev/data/b11:0' for '/devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sr0'.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-block.rules:16 GROUP="disk": Set group ID: 994
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-block.rules:16 MODE="660": Set mode: 0660
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-cdrom_id.rules:20 IMPORT{program}="cdrom_id --lock-media $devnode": Importing properties from results of "cdrom_id --lock-media /dev/sr0"
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Found callout binary: "/usr/lib/udev/cdrom_id".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Starting 'cdrom_id --lock-media /dev/sr0'
Oct 21 10:39:26 archetype (udev-worker)[3142]: Successfully forked off '(spawn)' as PID 3143.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_CD_R=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_CD_RW=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_R=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_RAM=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MRW=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MRW_W=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_BD=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_BD_R_SRM=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_BD_R_RRM=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_BD_RE=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_R_DL_SEQ=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_R_DL_JR=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_RW_SEQ=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_RW_RO=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_PLUS_RW=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_PLUS_R=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_PLUS_R_DL=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_CD=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_RW_REMOVABLE=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_RW=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_DVD_R_DL=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_BD_R=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MEDIA=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MEDIA_CD=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MEDIA_SESSION_COUNT=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MEDIA_TRACK_COUNT=11'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'cdrom_id --lock-media /dev/sr0'(out) 'ID_CDROM_MEDIA_TRACK_COUNT_AUDIO=11'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Process 'cdrom_id --lock-media /dev/sr0' succeeded.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-cdrom_id.rules:27 SYMLINK+="cdrom": Added device node symlink "cdrom".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:66 IMPORT{program}="ata_id --export $devnode": Importing properties from results of "ata_id --export /dev/sr0"
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Found callout binary: "/usr/lib/udev/ata_id".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Starting 'ata_id --export /dev/sr0'
Oct 21 10:39:26 archetype (udev-worker)[3142]: Successfully forked off '(spawn)' as PID 3144.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_TYPE=cd'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_BUS=ata'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_MODEL=HL-DT-ST_BD-RE_BH10LS38'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_MODEL_ENC=HL-DT-ST\x20BD-RE\x20\x20BH10LS38\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_REVISION=1.00'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_SERIAL=HL-DT-ST_BD-RE_BH10LS38_K98BBNF4019'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_SERIAL_SHORT=K98BBNF4019'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA_FEATURE_SET_PM=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA_FEATURE_SET_PM_ENABLED=0'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA_SATA=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA_SATA_SIGNAL_RATE_GEN1=1'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: 'ata_id --export /dev/sr0'(out) 'ID_ATA_PERIPHERAL_DEVICE_TYPE=5'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Process 'ata_id --export /dev/sr0' succeeded.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:78 SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}$env{.PART_SUFFIX}": Added device node symlink "disk/by-id/ata-HL-DT-ST_BD-RE_BH10LS38_K98BBNF4019".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:110 IMPORT{builtin}="path_id": Importing properties from results of builtin command "path_id".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:114 SYMLINK+="disk/by-path/$env{ID_PATH}$env{.PART_SUFFIX}": Added device node symlink "disk/by-path/pci-0000:00:13.0-ata-1.0".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:115 SYMLINK+="disk/by-path/$env{ID_PATH_ATA_COMPAT}$env{.PART_SUFFIX}": Added device node symlink "disk/by-path/pci-0000:00:13.0-ata-1".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-persistent-storage.rules:164 SYMLINK+="disk/by-diskseq/$env{DISKSEQ}$env{.PART_SUFFIX}": Added device node symlink "disk/by-diskseq/8".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/73-seat-late.rules:16 RUN{builtin}+="uaccess": Set command: uaccess
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/90-iocost.rules:18 IMPORT{builtin}="hwdb 'block::name:$env{.MODEL}:fwrev:$env{ID_REVISION}:'": Importing properties from results of builtin command "hwdb 'block::name:HL-DT-ST_BD-RE_BH10LS38:fwrev:1.00:'".
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: No entry found from hwdb.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/90-iocost.rules:18 IMPORT{builtin}="hwdb 'block::name:$env{.MODEL}:fwrev:$env{ID_REVISION}:'": Failed to run builtin "hwdb 'block::name:HL-DT-ST_BD-RE_BH10LS38:fwrev:1.00:'": No data available
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Setting permissions /dev/sr0, uid=0, gid=994, mode=0660
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Removing/updating old device symlink '/dev/disk/by-diskseq/4', which is no longer belonging to this device.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Symbolic link '/dev/disk/by-diskseq/4' points to '../../sr0' which is outside of '/dev/', updating it.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: No reference left for '/dev/disk/by-diskseq/4', removing
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Successfully created symlink '/dev/disk/by-diskseq/8' to '/dev/sr0'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Successfully created symlink '/dev/block/11:0' to '/dev/sr0'
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: sd-device: Created database file '/run/udev/data/b11:0' for '/devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sr0'.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Running built-in command "uaccess"
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: sd-device: Created database file '/run/udev/data/b11:0' for '/devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sr0'.
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: Device processed (SEQNUM=4036, ACTION=change)
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: sd-device-monitor(worker): Passed 1736 byte to netlink monitor.

and it seems to me the most relevant lines are

Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-block.rules:16 GROUP="disk": Set group ID: 994
Oct 21 10:39:26 archetype (udev-worker)[3142]: sr0: /usr/lib/udev/rules.d/60-block.rules:16 MODE="660": Set mode: 0660

But I wouldn't take my word for that.
At least I suspect that is what is responsible for the setting the permission to disk.
This is the line 16 in '60-block.rules'

SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", GROUP="disk", MODE="660"

---
Now the thrust of my thread are the following questions, for which I'd appreciate any comment:

It seems to me 'possibly' 'wrong' that defaults (wherever those should come from) should be to leave /dev/sr0, (being a removable media device, which also does not support posixy permissions,) with 'data' as the group. (?)
On the other hand its seems to me possibly 'correct' that the group is 'disk' (that is the case for /dev/sd* devices), but if that's the case, then why is the permission on /dev/sr0 'optical' before a disk is inserted?
what is likely to have been responsible for the .rules to be found under '/usr/lib/udev/rules.d'? what should be expected to populate them? (this is probably a silly question if you are familiar with linux but I'm not, I'd assume udev package, but only assume)

Very much a secondary question but: I'm tempted to just add a udev rule (albeit under /etc) for my need (non logging in user, that needs access to the drive) is there a proper/pattern way of doing this? (I've got be frank it kind of seems like there just isn't and that the nearest thing is actually on this occasion to change the group via udev. Udev doesn't seem to support extended acls, which is what I'd prefer. +tags are out as there is no user session (I think that's relevant?), I could run a script via udev but that doesn't seem to be the 'proper' means, scripts seem a bit iffy to be calling in udev, as does even just 'setafcl ...' (what happens if something hangs it up). Possibly system.d mount combined with fstab, again is that the proper way? Its not even clear to me if that would work, especially in the case of an audio cd, and usage like libcdio-paranoia.
As I say secondary question though.

Last edited by UO14 (2025-10-24 16:49:21)

unixman · 2025-10-21 22:03:03

'optical' reflect usage like libcdio-paranoia.
'disk' reflect disk like usage.

When something inserted; optical usage is gone because device is busy from now, because disk usage come and occupy:)
assumed disk like usage more common.

/usr/lib/udev/rules.d shared for all packages not owned by udev only.

WRT your need: there is tons of ways to accomplish it: from top of my head:

*add your app/service to optical group and overwrite mentioned udev rule. /run/udev overwrites /usr/lib/udev

Last edited by unixman (2025-10-22 13:36:52)

UO14 · 2025-10-22 10:42:37

Thanks unixman
However this disagrees with https://wiki.archlinux.org/title/Users_ … emd_groups .
Is there documentation for your assertion, if there isn't then justification or reasoning often serves in its place.

'disk' in this sense can almost be replaced with 'block-like', as far as I can tell, and almost no disk is useful to the user, or even the systems-administrator, as a 'block-type' device (at least not after its partitioned, the next step being formatting). The disk as a 'block-type' device is a concern for kernel/drivers. I would under stand if the above linked documentation omitted 'optical' entirely, and rolled '/dev/sr[0-9], /dev/sg[0-9]' up under 'disk'... but it does not. Even an audio cd has a block(like) structure https://en.wikipedia.org/wiki/Compact_D … _structure (I'd prefer to link something more authoritative but that's the IEC for you.) If after kernel/driver you're still having to concern yourself with storage as a block-like device, then the kernel/drivers, even the OS, hasn't done its job. Now it might need the systems-administrator to make some final decisions before getting to that place, but I think that's my point, how does one make those decisions? What is the pattern for those decisions? Documentation suggests 'a'-optical (which makes sense given mouting removable media is not a trivial as mounting fixed media), but I'm seeing 'b'-disk.

(There may be many ways, but they cannot all be of equal merit for some specific set of conditions, reinventing a wheel from first principles invites missing lessons already learned, that's not the main subject of my thread though. I already have my solution using udev, but that's just my solution.)

Coming at it from another angle: why change from 'optical' *to* 'disk'? (the purpose of the *group* is not to indicate that a disk is inserted, neither to the OS or the user, in case that's what you mean. Or if it is, I think that would need documentation.)

---

/usr/lib/udev/rules.d shared for all packages not owned udev only.

Thanks unixman, I'll need to look into that. At the very least, something for another thread.

Last edited by UO14 (2025-10-22 12:21:36)

unixman · 2025-10-22 14:02:02

WRT archwiki link it seems you are right. My above post is free speech; cough .. cough

philosophically thoughts:
optical is removable, random peoples maybe comes use optical then go.
it should be more relax.

But disk is more important and sensitive.
More low level as name imply.
it should be more strict.

So it is not perfect to use both for same device.

Last edited by unixman (2025-10-22 14:06:55)

seth · 2025-10-22 14:57:00

This is an extremely recent change in systemd 258
https://github.com/systemd/systemd/comm … 51fc5137f6

UO14 · 2025-10-23 11:09:23

Thanks unixman, thanks seth.
The fact seth, that you've linked to the main github for systemd tells me arch's systemd (I traced my 60-block file to systemd also) is not expected to be in anyway altered from that (which I should have guessed I suppose from what I've heard of the philosophy of arch). I don't know much about how package maintenance for distros works generally, much less any nuances between distros. (e.g. Looking at arch only, whether it is a given that each package is identical to the source.)

It seems to me like this might be a case of arch documentation isn't up with systemd, and in turn its not clear what systemd's intention is or why, so that's to be expected, where many systemd discussions are beyond the scope of any arch discussion.
I may have more of a look into systemd wise.

I won't put this thread to rest yet, but I won't be able to progress it for a while.

Last edited by UO14 (2025-10-23 11:19:32)

seth · 2025-10-23 11:23:23

Commit message looks like it's a haphazard hot fix for an unrelated problem that just hardcodes a group - have you tried the behavior w/o that patch?
(Ie just comment line 16 in 60-block.rules)

UO14 · 2025-10-23 12:44:34

Thanks seth.
----
Since the whole point of this thread is that its not clear what it should be doing, I can't call the following a fix, but its a workaround for what I needed.
/etc/udev/rules.d dropfile "65-cdrom_id.rules" . It's rather overkill in some respects, but that's because my lack of experience means I have to be paranoid about any later refactoring, or simply not having understood the full implication of something.

# a combination of /lib/udev/rules.d/... 60-cdrom_idrules (cd rom specific iding) and 60-block.rules where the group disk was set that we want to override.

ACTION=="remove", GOTO="cdrom_end"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|vdisk*|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", GOTO="cdrom_end"

# import device and media properties and lock tray to
# enable the receiving of media eject button events
IMPORT{program}="cdrom_id --lock-media $devnode"

#If it's an audio CD, then set the group to 'optical'. This may be useful for other formats with further refinement/generalization, but in this case we are trying to limit the impact of this customization, to the present need only.
KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1", SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", ENV{ID_CDROM_MEDIA_CD}=="1", ENV{ID_CDROM_MEDIA_TRACK_COUNT_AUDIO}=="?*", GROUP="optical", MODE="660"

LABEL="cdrom_end"

---
pacman -Qo /usr/lib/udev/rules.d/60-block.rules results in
/usr/lib/udev/rules.d/60-block.rules is owned by systemd 258.1-1

The problem with this file is that

# Reset access rights to each loopback device once it gets detached.

is not what ....

SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", ,,,"

necessarily means I don't think? Unless "detached" means something other than I understand it to.
This ENV{DISK_MEDIA_CHANGE}=="1" is as good for an insert as it is an eject. There is a test that can be done for eject. But then this rules file is covering far more than just removable media.
If I had to guess the solution to this is a more specific override outside of block. (sort of my workaround)
But its hard to even suggest an issue, if the design intention isn't clear.
(For example, it would be interesting to see if systemd udev attempts to assert group 'optical' anywhere at all. It may not. It may consider this to be a concern above systemd.)

Last edited by UO14 (2025-10-23 13:57:50)

seth · 2025-10-23 12:55:18

Please clarify whether

SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", GROUP="disk", MODE="660"

is really the only thing that leads to the undesired group ownership and if so the correct action would be to file a bug because that

seth wrote:

looks like it's a haphazard hot fix for an unrelated problem

Keep in mind that you're talking about optical devices here - I can't test that because I don't have one around and for the same reason it was likely no concern when hardcoding that rule to disk.

UO14 · 2025-10-23 13:23:37

Well
https://github.com/search?q=repo%3Asyst … &type=code
suggests that systemd doesn't 'anywhere' consider it it's business to assert group='optical'

I think if I were to open an issue under github, it would be along the lines of
"don't have a clue what I'm doing - is it systemd's job to help with optical/removable disk access? (I ask because...)"
I'll think on it...

I have to say I'm starting to think it's not, and that therefore this is not bug. Which was among where I was going with this thread.
It just seems like removable media, certainly optical, has been handed over to the desktop environments, and other than that it, and the groups concerned with it ('optical') have just slipped through the cracks and is now nobodies business.
That said on the other hand... udev is doing 'stuff' with cdroms.

What I really need next is some sort of linux/authoritative source to backup the original arch document as something more than a mere serving suggestion https://wiki.archlinux.org/title/Users_ … emd_groups
E.g. what set 'optical' after boot in the first place? Maybe that will offer clarity.

For other distros this might be something they are taking it upon themselves to 'add/customize', but I guess that's not arch's style.
Maybe something for arch documentation/guide if a systemd question doesn't turn up anything.

Last edited by UO14 (2025-10-23 13:25:31)

UO14 · 2025-10-23 13:37:02

Oh, I forgot to answer,

seth wrote:

Please clarify whether
SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", GROUP="disk", MODE="660"
is really the only thing that leads to the undesired group ownership...

sorry.

As far as I can tell it is. But then again, as of examining the matter in this thread to today, I'd say its more like systemd/udev just doesn't care what the group of an sr[0..9] device is at all. Only that it's yet another block type device.
Suffice to say, I can address the matter with my own udev workaround, which hints that this is the only thing asserting it. My udev logging also supports this. If there were anything beyond this though, I wouldn't know where to start looking, again my udev workaround holds, so if there is... its happening after or before rule 60- but before my udev 65.

seth · 2025-10-23 13:38:54

/usr/lib/udev/rules.d/50-udev-default.rules originally sets the group.

As for the current situation:
Comment that line, reload udev (or reboot) and see/prove whether the GID of sr0 still changes.
Apparently his is regressive behavior introduced by that patch and that's all you need to know to have a point.

The new behavior being "unintentional" is a guess (from the commit message) but a fair one and then this needs to be addressed correctly or retcon'd as "I meant to do that".

UO14 · 2025-10-23 14:14:27

seth wrote:

/usr/lib/udev/rules.d/50-udev-default.rules originally sets the group.
...

well I'm not surprised that my attempt to search for that via github failed, since I don't really know how github works.
Thanks again seth.
It's my intention to do that testing, but I'm going to be unavailable for some days, and I've probably run out of time for now with this last comment.
I'll have to do some testing, check github for known issues (google what retcon means... XD )
If anyone beats me to it obviously post here so that we are not doubling up.
Thanks seth, thanks all

UO14 · 2025-10-23 15:43:42

I've disabled my workaround .rules file, commented out line 16 of 60-block.rules . rebooted.
Can confirm that inserting a cd-rom has seen the behavior change, group now 'remains' optical, instead of changing to 'disk'.

UO14 · 2025-10-23 16:24:41

Thanks for your help seth. I've logged a bug at github systemd
https://github.com/systemd/systemd/issues/39426

UO14 · 2025-10-24 16:48:35

[SOLVED]
https://github.com/systemd/systemd/issues/39426
now has commits with pull request pending so I think we can take that as bug confirmed.
From here on follow there for further.
I'll try to confirm here once fix makes it into arch, for completeness sake, but from here on this either isn't a matter for arch, or would be better served by new thread.

Last edited by UO14 (2025-10-24 16:55:43)

Arch Linux

#1 2025-10-21 13:28:28

[SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#2 2025-10-21 22:03:03

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#3 2025-10-22 10:42:37

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#4 2025-10-22 14:02:02

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#5 2025-10-22 14:57:00

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#6 2025-10-23 11:09:23

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#7 2025-10-23 11:23:23

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#8 2025-10-23 12:44:34

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#9 2025-10-23 12:55:18

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#10 2025-10-23 13:23:37

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#11 2025-10-23 13:37:02

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#12 2025-10-23 13:38:54

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#13 2025-10-23 14:14:27

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#14 2025-10-23 15:43:42

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#15 2025-10-23 16:24:41

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

#16 2025-10-24 16:48:35

Re: [SOLVED]setting of /dev/sr0 group to 'disk' seems possibly wrong

Board footer