External SATA (eSATA) removable disk not auto mounted

Binary package hint: hal

I have posted about this in bug 115768 as well and will copy most of what I've written there.

I am using the latest Kubuntu 7.10 (which by now should be all but properly released) with KDE 3.5.7:

Linux thehostname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Upon plugging in an external, removable SATA (eSATA) hard disk formatted with Ext3 I get the following messages in .xsession-errors:

kded: ERROR: mount failed for /org/freedesktop/Hal/devices/volume_uuid_6591d79f_e4db_4fb6_9edd_fdc18d5a9731: org.freedesktop.Hal.Device.PermissionDeniedByPolicy - hal-storage-fixed-mount refused uid 1000
kded: ERROR: mounting /org/freedesktop/Hal/devices/volume_uuid_6591d79f_e4db_4fb6_9edd_fdc18d5a9731 returned hal-storage-fixed-mount refused uid 1000

Dolphin (D3lphin) says "hal-storage-fixed-mount refused uid 1000", too.

Manually issuing "pmount /dev/sdb1 /media/mydisk" says:

Error: device /dev/sdb1 is not removable

Which is consistent with the lshal output saying "storage.removable = false (bool)" for that disk.

Manually mounting (i.e. with mount, not pmount) works fine. Creating an entry in /etc/fstab and mounting via that works fine, too, both as a regular user and as root.

I am not sure what exactly the underlying problem is, but I suspect that noone has yet thought of describing a policy for removeable, external SATA disks (formatted Ext3)? What does it take to write a suitable policy? This also seems to be purely a HAL problem, not KDE-, kernel- or even hardware-related. I am attaching the output of lshal, hald, dmesg, etc as required by https://wiki.ubuntu.com/DebuggingRemovableDevices as well.

Same problem/error message here. But not with all external drives. (Also KDE, Konqueror as default filemanager)

Some USB-harddisks just mount fine (automatical and with pmount) and other fail with automount but are working with pmount. It seems to me as USB-Flashdrives are always working (automatical and pmount).

How is HAL decideing which is an removable and which not?

Daniel Weigl

I have the same problem with an external eSATA drive with two partitions: ext3 and ntfs.
Even the ntfs partition show the same problem, I think it doesn't depend on the filesystem

#man pmount
gives:

The mount will succeed if all of the following conditions are met:

       · device is a block device in /dev/

       · device is not in /etc/fstab (if it is, pmount executes mount device
         as the calling user to handle this transparently). See below for more
         details.

       · device is not already mounted according to /etc/mtab and /proc/mounts

       · if the mount point already exists, there is no device already mounted
         at it and the directory is empty

       · device is removable (USB, FireWire, or MMC device, or
         /sys/block/drive/removable is 1) or whitelisted in /etc/pmount.allow.

       · device is not locked

so i putted my device in /etc/pmount.allow,

which worked for /dev/sdXX, but unfortunately not for an entry in the form of /dev/disk/by-uuid/MY_LONG_UUID - which is a pity ...

Joe

this bug exists in the jaunty jackalope alpha as well with 2.6.28-4-generic #11-Ubuntu SMP kernel and ubuntu proposed repsository enabled, updated, and applied as of Jan 19, 2009.

External hdd have more and more often an esata connection for great performances. But Ubuntu refuse to mount it automatically. It's a bad point.

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.

Setting Medium importance, and marking as Confirmed as there are people here confirming this as well as upstream. In Jaunty, please run "apport-collect 153768" (without quotes). This will provide more system specific information which may be helpful in debugging/triaging. Thank you.

It's not exactly a hardware-specific thing. IIRC, it's just that the lower
levels of the system have no conception of SATA as anything but internal.

I understand, but I'm pretty sure the developers would probably like to have this information to have a look at :)

Here my comment on freedesktop bug (without answer) :

Can hal simply consider that under a running sytem, when a new sata drive
appear (eSATA or SATA, because technically SATA dd are hotpluggable), it should consider it as removable/hotplug and so Gnome can automount it ?

Re-marking Incomplete. In Jaunty, please run "apport-collect 153768" with these SATA drive(s) connected. Thank you.

Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: hal 0.5.12~rc1+git20090403-0ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=fr_FR.UTF-8
Uname: Linux 2.6.28-11-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers

That didn't quite worked how I hoped... Can you provide the information requested at https://wiki.ubuntu.com/DebuggingHal and attach the log files here as separate attachments? Thanks.

hal.log

lshal.txt

kern.log

Quick response, nice to see :)
Marking Triaged. I believe there is now enough information here, so I shall consider this as triaged, and let the developers take it from here. Thanks again!

@Teej : your welcome.

Regards

Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: hal 0.5.12~rc1+git20090403-0ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-11-generic x86_64
UserGroups: adm admin audio cdrom dialout fuse lpadmin netdev plugdev sambashare vboxusers video

Having the same problem on current karmic, using the sata_sil24 driver.
I have to mount the volume manually and enter my password.

02:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
 Subsystem: Silicon Image, Inc. Device 7132
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at f9efbf80 (64-bit, non-prefetchable) [size=128]
 Memory at f9efc000 (64-bit, non-prefetchable) [size=16K]
 I/O ports at cc80 [size=128]
 Expansion ROM at f9f00000 [disabled] [size=512K]
 Capabilities: [54] Power Management version 2
 Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
 Capabilities: [70] Express Legacy Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting <?>
 Kernel driver in use: sata_sil24

For me, the problem is even more irritating... if I hotplug my eSATA drive that has two partitions (one NTFS and one ext3), it pops up an authentication dialog for one (and is MISSING the "remember this" feature!).... and for the other, it just plain says "Not Authorized". But perhaps that's a separate bug.

Also, a comment on this:
"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."

I beg to differ.... I see nothing in /sys that indicates a framework for showing what's hotpluggable. If there were such a framework, I'd expect devices to have a "hotpluggable" property that's always false... but instead, there is no such attribute. This means that even if the controller tells the kernel whether it's hotpluggable, the kernel just plain ignores that info -- and thus this is a kernel issue.

Interestingly enough, the eSATA-is-external detection works perfectly fine out-of-the-box in Vista and Win7.

Also: Since HAL has been deprecated, and replaced by devkit-disks in Karmic, shouild we attach this bug to the corresponding package now?

Unsurprisingly devkit-disks shows the same behaviour, see bug 465054.

Realistically we won't ever fix this in hal, because of https://wiki.ubuntu.com/Halsectomy .

I just read the upstream kernel bug. If not even the kernel has a way of detecting this, we can't detect it in dk-disks either. The proposed whitelist seems cumbersome to maintain, and not really robust either.

It's also pretty much a moot point now with the more general fix in bgu 465054.

As seen in kernel.org bug report: "Rejecting as INVALID. If someone has a machine with working ahci external port marking, I have patches to test but given that most other controllers don't have such feature, I think we need hal whitelisting one way or the other." -- hmm, I could use such patches, since I can say that my external port marking DOES work. Are these patches available on a mailing list somewhere?

(It also makes me wonder: why make it difficult by not posting those patches on the upstream bug-report itself?)

I have aa ASUS M3N78 Pro mobo with AHCI enabled on the sata ports and 2 of them are set as esata and wired to ports on the back of the case. They worked fine, automounting in jaunty, but after a clean install of 64 bit karmic, where they worked for a short time, after a few updates, they stopped automounting. They do show up in Places, listed right under the "Computer" icon. Clicking on them will mount the drives. One is NTFS and just mounts, the other has a full install of 32 bit 9.10 in ext3 and requires authentication to mount. I'm not convinced this is a bug, it may be a feature. The external esata drives are behaving exactly the same way my 2nd internal sata drive behaves. It does not automount unless I put it in /etc/fstab. This is fine for an internal dirve, but I would not want to put the externals in fstab, So as long as they show up in Places, it's not a problem. As long as I have 1 or 2 click access to the drives, it's ok. Adding the "Disk Mounter" to the top panel will give you a quick visual on when the drives are detected and let you mount and unmount them from there.

While I can see the difficulty in solving this problem, I do see it as a bug. If nothing else it's a functionality hindrance. From a system perspective there's no real distinction between a SATA port and an eSATA port, if I'm understanding things correctly. However, from a user's perspective, plugging in a USB drive "just works" and the drive is mounted and ready to go. Now, plugging the very same drive in via eSATA results in it not being mounted. In fact mounting it (under 9.10) requires a password. While some might not see this as much of an annoyance, I'm sure others like myself do.

Reopening for udisks, since we can't detect that in the kernel either.

Attaching kernel patch to export the AHCI external port bit.

@Phillip -- that patch looks promising, it would probabally be appropriate to send that upstream. The maintainers for that are listed below:

M: Jeff Garzik <email address hidden>
L: <email address hidden>

I hope that "external" attribute can be generalized to more hardware, such as Silicon Image SATA controllers.

@Andy -- I did. He replied that as I had already pointed out, the information is already exported in sysfs in another file. I replied that it is unusable there because the file is in the wrong place, and because udev doesn't do bitwise comparisons. He never replied. Maybe I'll poke him again about it.

@Dana: That is an AHCI controller ( pretty sure just about ALL sata controllers are ), so this would apply to it.

This looks promising but needs to be an upstream solution. I've set the bug state to incomplete - please set it back if/when there's a solution from Jeff.

Thanks

That is not correct usage of the incomplete state. Please see https://wiki.ubuntu.com/Bugs/Status.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

The attachment "0001-PATCH-Export-ahci-eSATA-attribute.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Based on this commit, it looks like "Export-achi-eSATA-attribute" is already up stream, in both the userspace and kernel parts.

http://cgit.freedesktop.org/hal/commit/?id=dea5997df8966719d707b7136621ffd37f69a4d7

This should be working on Oneric, the only thing that's left is to test.

Ayan pointed out that this is filed against udisks since HAL is deprecated. Ignore the previous comment.

This bug conflates eSATA detection and automounting. The current kernel does not support ahci 1.3 external or hotpluggable bits so udisks has no way of getting this information.

We should probably make two bugs -- one for kernel support and another for udisks support.

Why did you mark this as won't fix? The last time I spoke with pitti and others about this, the conclusion was that udisks can not and should not determine if a device is internal or external, but rather it should auto mount all devices, except those that were detected at install time and left unconfigured.

@Philip Susi -- I marked it as "Wont Fix" in part because this doesn't seem to be a well defined bug. The description talks about HAL but marks udisks as affected.

If the plan is to automount anything "new" then that is solely a udisks issue and maybe we need a bug with a clearer title and description.

Sounds like it should be "Incomplete" instead of "Won't Fix". Could someone (who can) please change the status?

It talks about HAL because that was the component responsible at the time the bug was originally filed way back when. I'll clean up the description a bit.

I think that you should remember that all SATA hdd's are hot-pluggable.

So, the problem above not only affects users that want to attach HDD to eSATA port, but also backplane owners such as:

http://www.chieftec.eu/en/accessories/sas-sata-backplanes/snt-2131sata.html

For me this is serious bug and I lost a lot of time studying and writing udev rule to automatically mount my HDD's in backplane.

Hi Marcin,

Would you please attach that udev file? We're interested in the differing use cases here, in particular how to determine which devices need to be automounted via udisks (such as backplane) and which need to be manually mounted or not mounted (root, SAN LUNs).

Marcin, I, too, would love to see your udev rule.

I have a LUKS-encrypted partition on a SATA drive which I can hot-plug into the slot on my laptop where the DVD drive normally goes.

Just upgraded from Ubuntu 10.04 to 12.04 and what used to work perfectly now does not work.

eSata drive connected, see in dmesg that partitions are detected but not automount when valid UUID entries are in /etc/fstab.

Partitions mount when drive plugged in on system boot. Now have to manually mount partitions after post-boot connection.

@dcstar

Just confirming that I can't get our 12.04 Server to automount on drive reinsertion either. Drive and partitions recognised by the system but won't automount.

I have this issue in Ubuntu Quantal 12.10

So I have an idea I'm working on to finally fix this. Udisks could be modified to look for a udev attribute that indicates the drive is connected via esata, and treat the drive correctly. This attribute could be imported from the parent ata port, if it is known that the port is an esata port. The udev hwdb could be configured to know that a specific port on specific known motherboards is esata.

I'm still trying to sort out how to set up such a matching rule in the udev hdwb though since there doesn't seem to be a way to match on multiple requirements joined by AND rather than OR.

I have Ubuntu 12.04 desktop, and my newly external drive(ext4) connected to the computer through eSATA interface, is not automatically mounted when I turn it on. Manual mounting works ok. Would be nice to have it automatically mounted when turned on! I am planning to install the latest desktop LTS... i hope it will be auto mounted there!