Here's my cdrom device node and symlink: brw-rw---- 1 root cdrw 22, 0 2006-08-07 14:54 /dev/hdc lrwxrwxrwx 1 root root 3 2006-08-09 15:31 /dev/cdrom -> hdc Now I try this (with hal-0.5.7-r3 and kdebase-kioslaves-3.5.4): kio_media_mounthelper /dev/hdc I get a messagebox saying "Permissions denied" while the following is printed in virtual console: kded: error: mount failed for /org/freedesktop/Hal/devices/volume_label_BACKUP_1: org.freedesktop.Hal.Device.Volume.PermissionDenied - /dev/cdrom found in /etc/fstab kded: error: mounting /org/freedesktop/Hal/devices/volume_label_BACKUP_1 return Permissions denied I have the following entry in /etc/fstab: /dev/cdrom /mnt/cdrom iso9660 user,noauto If I replace "/dev/cdrom" with "/dev/hdc" in fstab, it gets mounted OK (mounted at /mnt/cdrom): /dev/hdc on /mnt/cdrom type iso9660 (ro,noexec,nosuid,nodev,user=joel) If I remove the fstab line completely, it works too (mounted at /media/disk): /dev/hdc on /media/disk type iso9660 (ro,noexec,nosuid,nodev,noatime,uid=1000,utf8) If I try: kio_media_mounthelper /dev/cdrom I get: file:///dev/cdrom cannot be found But this is not a problem, since KDE's storage applet never calls kio_media_mounthelper with a symlink as argument. But the impossibility to use /dev/cdrom in fstab *is* a problem, especially with USB devices where the device name can change all the time. I remember, with older versions of KDE & hal, it used to work. Can someone reproduce this problem ?
Evil code is inside check_fstab() routine, in file /usr/share/hal/scripts/hal-system-storage-mount. It uses udevinfo as in: udevinfo -q symlink -n /dev/hdc This produces: cdrom cdrw dvd dvdrw I have very bad awk knowledge, but I think it adds /dev/ in front of each device name, which produces: /dev/cdrom /dev/cdrw /dev/dvd /dev/dvdrw If any of those are found inside /etc/fstab, the mount is refused. How convenient :-/
Mmh.. seems official: http://webcvs.freedesktop.org/hal/hal/ChangeLog?r1=1.807&r2=1.808 "tools/hal-system-storage-mount: Refuse to mount a volume if it's already listed in /etc/fstab - includes checking symlinks. Patch from Ludwig Nussel <ludwig.nussel@suse.de>." 2006-02-14 David Zeuthen <davidz@redhat.com> Anyhow: On 2006-03-06 this functionality has been turned into C code. See: http://webcvs.freedesktop.org/hal/hal/tools/hal-storage-mount.c?view=markup Still the same behaviour, I guess: fprintf (stderr, "org.freedesktop.Hal.Device.Volume.PermissionDenied\n"); fprintf (stderr, "Device %s is listed in /etc/fstab. Refusing to mount.\n", device); exit (1); Argh !!
First I have to say, that I'm totally off with regards to this functionality, since I've only rarealy to deal with portable media, so I don't feel the pressure to become aquainted with it. I can follow the idea, not to want to interfere with stuff mounted via fstab. The symlink problem is indeed a KDE one: https://bugs.kde.org/show_bug.cgi?id=132523 >But the impossibility to use /dev/cdrom in fstab *is* a problem, especially >with USB devices where the device name can change all the time. Why do you need to have it mounted there? I thought udev rules and hotplug are they way to go, if I got that right. gentopia team: Would you be so nice and drop a line on the hal/fstab issue, please?
At first, I simply wanted to keep using /mnt/cdrom, as I (and some programs) were used to it. :-) Yes, after looking at changelogs for pmount, it seems the trend is really to prevent (at all levels) fstab entries from being mounted. Well I admit, after all, that mountpoint and symlinks are mostly a cosmetic issue when dealing with hotplug devices. *However*, the fstab entry allowed to use quote important mount options (such as enabling "noatime" and/or disabling "sync") for dvd-ram media. Yet, all options I tried in /etc/hal/fdi/information/xyz.fdi get ignored when mounting. This is the problem IMHO. The "volume.policy.desired_mount_point" directive works perfectly (to select mountpoints in /media) but I can't modify mount options at all... Has someone had any success/effect with storage.policy.mount_option.* from HAL 0.5.8 specification ?
(In reply to comment #3) > The symlink problem is indeed a KDE one: > > https://bugs.kde.org/show_bug.cgi?id=132523 Been fixed upstream 4 months ago. The rest here is a hal 'feature' or whatever you call it, not a Gentoo business.
