Hard drives connected by eSATA are hotpluggable from the end-user's perspective, but HAL erroneously considers them to be fixed. This causes problems for users on distros that forbid normal users from mounting fixed drives as a security precaution (e.g., Debian, Ubuntu). Meanwhile, using the same drive as a USB device via an eSATA-to-USB adapter works correctly. Further, manually mounting the eSATA device as root works as correctly. Steps to reproduce: 1) Obtain a computer with an eSATA port, an eSATA drive, and an eSATA-to-USB adapter. 2) Setup HAL to give your user account the hal-storage-removable-mount permission but not the hal-storage-fixed-mount permission (this is hard-coded in Debian because it does not have PolicyKit yet; see http://people.debian.org/~terpstra/message/20070807.181731.32cacc62.en.html). 3) Plug in the drive via USB and observe that it mounts automatically. 4) Plug in the drive via eSATA and observe that it erroneously fails to mount, giving the following error message: Cannot mount volume. Error org.freedesktop.Hal.Device.PermissionDeniedByPolicy. -> Details hal-storage-fixed-mount refused uid 1000 5) Try to open the drive in Nautilus and observe the same error. Try to mount it with gnome-mount as yourself (e.g., "gnome-mount -d /dev/sdb1") and observe the same error. 6) Mount the eSATA drive manually as root (e.g., "sudo gnome-mount -d /dev/sdb1" or "sudo mount /dev/sdb1 /media/disk") and observe that it works and that the drive is accessible. Expected behaviour: eSATA drives should be considered to be hotpluggable, and thus the normal user account should be able to successfully mount the eSATA drive (either automatically as in step 4 or manually as in step 5). For an end user who switches from a USB connection to eSATA to get the extra speed (me), the error message is a rude awakening. I have observed this bug on Debian Etch/Lenny 2.6.18-5 amd64 for each of the following package versions for hal and libhal-storage1: 0.5.8.1-9 0.5.9.1-2 0.5.9.1-4 For the latter two tests, hal-info was 20070618-1. For all three, libhal1 was version 0.5.9.1-2, but I'd imagine the bug is not in libhal. Some info on my system: it is a Dell XPS M1710 laptop with a Core 2 Duo. The eSATA port actually comes from an eSATA-to-ExpressCard adapter, which requires only the pciehp kernel module (which on my system must be loaded with the option pciehp_force=1). The output of lshal -m follows. When inserting via USB: $ lshal -m Start monitoring devicelist: ------------------------------------------------- 19:25:10.144: usb_device_152d_2338_7CA0D1820141 added 19:25:10.204: usb_device_152d_2338_7CA0D1820141_if0 added 19:25:10.222: usb_device_152d_2338_7CA0D1820141_usbraw added 19:25:15.164: usb_device_152d_2338_7CA0D1820141_if0_scsi_host added 19:25:15.165: usb_device_152d_2338_7CA0D1820141_if0_scsi_host_scsi_device_lun0 added 19:25:15.195: usb_device_152d_2338_7CA0D1820141_if0_scsi_host_scsi_device_lun0_scsi_generic added 19:25:15.263: storage_serial_WDC_WD32_WD_WCAPD1820141_7CA0D1820141 added 19:25:15.301: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda added 19:25:15.492: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda property volume.mount_point = '/media/disk-1' 19:25:15.497: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda property volume.is_mounted = true When inserting via eSATA: $ lshal -m Start monitoring devicelist: ------------------------------------------------- 19:28:41.331: pci_197b_2360_scsi_host added 19:28:41.333: pci_197b_2360_scsi_host_scsi_device_lun0 added 19:28:41.353: pci_197b_2360_scsi_host_scsi_device_lun0_scsi_generic added 19:28:41.415: storage_serial_SATA_WDC_WD3200KS_00_WD_WCAPD1820141 added 19:28:41.442: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda added Viewing the lshal output for that storage ID confirms that it does not realize that the eSATA drive is hotpluggable (see indicated line): udi = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_WD3200KS_00_WD_WCAPD 1820141' block.device = '/dev/sdb' (string) block.is_volume = false (bool) block.major = 8 (0x8) (int) block.minor = 16 (0x10) (int) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_W D3200KS_00_WD_WCAPD1820141' (string) info.capabilities = {'storage', 'block'} (string list) info.category = 'storage' (string) info.parent = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_host_scsi_devic e_lun0' (string) info.product = 'WDC WD3200KS-00P' (string) info.udi = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_WD3200KS_00_W D_WCAPD1820141' (string) info.vendor = 'ATA' (string) linux.hotplug_type = 3 (0x3) (int) linux.sysfs_path = '/sys/block/sdb' (string) storage.automount_enabled_hint = true (bool) storage.bus = 'scsi' (string) storage.drive_type = 'disk' (string) storage.firmware_version = '21.0' (string) storage.hotpluggable = false (bool) <-------------------- WRONG storage.lun = 0 (0x0) (int) storage.media_check_enabled = false (bool) storage.model = 'WDC WD3200KS-00P' (string) storage.no_partitions_hint = false (bool) storage.originating_device = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_ host_scsi_device_lun0' (string) storage.partitioning_scheme = 'mbr' (string) storage.physical_device = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_hos t_scsi_device_lun0' (string) storage.removable = false (bool) storage.removable.media_available = true (bool) storage.removable.media_size = 320072933376 (0x4a85d56000) (uint64) storage.requires_eject = false (bool) storage.serial = 'SATA_WDC_WD3200KS-00_WD-WCAPD1820141' (string) storage.size = 320072933376 (0x4a85d56000) (uint64) storage.vendor = 'ATA' (string) Thanks in advance, and good luck! I certainly hope that it does not turn out to be impossible to distinguish between eSATA drives and internal SATA drives ...
Please provide the complete lshal output as attachment
Created attachment 11260 [details] Output of running "lshal" after plugging in the drive via eSATA and getting the error
Btw, I have confirmed this now on 2.6.22-1 too, and that's the kernel that I used for the lshal attachment.
what print: grep . /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/*
$ grep . /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/* grep: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/delete: Permission denied /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/device_blocked:0 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iocounterbits:32 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iodone_cnt:0x16625 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/ioerr_cnt:0xd /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iorequest_cnt:0x16625 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/modalias:scsi:t-0x00 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/model:Hitachi HTS72101 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/queue_depth:1 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/queue_type:none grep: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/rescan: Permission denied /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/rev:MCZO /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_level:6 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/state:running /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/timeout:30 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/type:0 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:DRIVER=sd /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:PHYSDEVBUS=scsi /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:PHYSDEVDRIVER=sd /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:MODALIAS=scsi:t-0x00 /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/vendor:ATA
Looks to me as if we can't do anything here atm. I see no way to differ between SATA and eSATA. Maybe the kernel guys know more if this is possible at all.
I was afraid of that. I'll leave it to you guys to open a bug at kernel.org or whatever. As an experienced user/engineer, having to run "sudo gnome-mount" in a terminal doesn't bother me too much. Once eSATA becomes more common though, I think you'll get a lot more complaints. Thanks.
One last thing: If worst comes to worst, you might want to consider making _all_ SATA drives count as hotpluggable (because technically they are), and then tell the Debian/Ubuntu people to find a better way to enforce their security ideals. Just my two cents.
hello there, this issue is starting to get a bit old. Did someone contact the kernel guys ? our downstream issue is at: https://bugs.gentoo.org/show_bug.cgi?id=260409
Add myself to CC. External hdd have more and more often an esata connection for great performances. But the system refuse to mount it automatically. It's a bad point.
Upstream bug on kernel : http://bugzilla.kernel.org/show_bug.cgi?id=12898
From upstream : Currently, the only controller which has a way to tell the kernel whether a port is external or not is ahci. Unfortunately, there doesn't seem to be many machines which actually use the facility. I haven't seen any yet. The only workable solution seems to be developing eSATA whitelist on the hal side.
Can hal simply consider that under a running sytem, when a new sata drive appear (eSATA), it should consider it as removable/hotplug and so Gnome can automount it ?
Here is a hal rule I've put in my preferences.fdi which works for me in my case where I have an external esata drive plugged into a esata cardbus adapter in my laptop. I think it should work for anyone in a similar situation. Note that you have to either put it before, or comment out the other entry in the preferences.fdi that prevents automounting internal drives. I'll attach the full /etc/hal/fdi/policy/preferences.fdi. The rule: <!-- Fix properties for external esata drives connected via cardbus --> <match key="block.device" exists="true"> <match key="block.is_volume" bool="false"> <match key="storage.removable" bool="false"> <match key="@info.parent:@info.parent:@info.parent:@info.parent:info.linux.driver" string="pcieport-driver"> <merge key="storage.removable" type="bool">true</merge> <merge key="storage.hotpluggable" type="bool">true</merge> </match> </match> </match> </match>
Created attachment 26669 [details] /etc/hal/fdi/policy/preferences.fdi
You can't actually distuingish SATA from eSATA ports - I'm using an eSATA bracket which is internally connected to a SATA port. Looks like this: http://www.cooldrives.com/essaii3gbexp.html
And I have one of these: <http://www.scan.co.uk/Products/Icy-Dock-MB-453SPF-Fits-into-2-525-Bays-Hosting-3-SATA-SATAII-Hard-Drive-with-Hot-swapable>, that connects via SATA internally. IMHO, all drives should be hot-pluggable. There is no harm in this because if they are mounted by HAL on behalf of a user, they will be mountned with nodev,nosuid and other appropriate options. If they are mounted by root then the exact options that the administrator desires will be given on the 'mount' command line, or in /etc/fstab, etc.
I agree, all SATA drives should be considered hotpluggable. After all, they really are. Even an internal SATA drive can be unmounted and removed while the computer is on. Of course non-SATA internal drives should still be reported as not hotpluggable, since they aren't (e.g., IDE).
This more general rule works for me and might work for any SATA drive, but I can't be sure as I only have my own to test it on: <match key="block.device" exists="true"> <match key="block.is_volume" bool="false"> <match key="storage.removable" bool="false"> <match key="@info.parent:linux.subsystem" string="scsi"> <match key="@info.parent:scsi.vendor" string="ATA"> <merge key="storage.removable" type="bool">true</merge> <merge key="storage.hotpluggable" type="bool">true</merge> </match> </match> </match> </match> </match>
For informations, I'v this problem on Ubuntu 9.04, but not in Fedora 11
e-SATA hotplug support was fixed in HAL with those commits: http://cgit.freedesktop.org/hal/commit/?id=dea5997df8966719d707b7136621ffd37f69a4d7 http://cgit.freedesktop.org/hal/commit/?id=829968ed2ace38908db3ead8204d544d7198159f http://cgit.freedesktop.org/hal/commit/?id=23267656d59fe56cb6401f65a278c3ee2b32de39
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.