External SATA (eSATA) removable disk not auto mounted

Bug #153768 reported by Andreas Ntaflos on 2007-10-17
174
This bug affects 23 people
Affects Status Importance Assigned to Milestone
HAL
Fix Released
Medium
Linux
Invalid
Medium
OEM Priority Project
Medium
Chris Van Hoof
Oneiric
Undecided
Unassigned
hal (Ubuntu)
Low
Unassigned
linux (Ubuntu)
Medium
Unassigned
udisks2 (Ubuntu)
Medium
Unassigned

Bug Description

eSATA disks are are not auto mounted when plugged in. This is because udisks uses a heuristic to decide if it should auto mount a drive. The heuristic is motivated by the desire to not auto mount internal disks/partitions that belong to other operating systems. The heuristic currently makes the assumption that disks connected via a usb bus are external, and disks connected with other buses ( sata, scsi ) are internal, and thus does not mount them. This heuristic is inherently unreliable as usb disks can potentially be internal, and sas/sata disks can be external. Thus, the heuristic needs to be disabled, and all unknown disks need to be auto mounted. Disks detected but left unconfigured at install time should have entries in /etc/fstab set to noauto to prevent their being auto mounted.

Please provide the complete lshal output as attachment

Created an attachment (id=11260)
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.

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.

Andreas Ntaflos (daff) wrote :
Andreas Ntaflos (daff) wrote :
Andreas Ntaflos (daff) wrote :
DanWei (danielweigl) wrote :

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

Claudio (lancos) wrote :

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

Changed in hal:
status: Unknown → Confirmed
joe richter (joe-r) wrote :

#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

zertz (zertz) wrote :

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.

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.

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 ?

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.

Changed in linux:
status: Unknown → Confirmed

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.

Changed in linux:
status: Confirmed → Invalid

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.

Changed in hal (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed

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.

Changed in hal (Ubuntu):
status: Confirmed → Incomplete

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

Changed in hal (Ubuntu):
status: Incomplete → Confirmed

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.

Changed in hal (Ubuntu):
status: Confirmed → Incomplete

hal.log

lshal.txt

kern.log

Changed in hal (Ubuntu):
status: Incomplete → Confirmed

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!

Changed in hal (Ubuntu):
status: Confirmed → Triaged

@Teej : your welcome.

Regards

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 <email address hidden>:@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 an attachment (id=26669)
/etc/hal/fdi/policy/preferences.fdi

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

mwoods (woods-marvin) wrote :

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 <email address hidden>:linux.subsystem" string="scsi">
          <match <email address hidden>: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

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

Dana Goyette (danagoyette) wrote :

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.

Dana Goyette (danagoyette) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in devicekit-disks (Ubuntu):
status: New → Triaged
summary: - External SATA (eSATA) removable disk (formatted with Ext3) not mounted
- automatically: hal-storage-fixed-mount refused uid 1000
+ External SATA (eSATA) removable disk detected as system-internal
Changed in devicekit-disks (Ubuntu):
importance: Undecided → Low
Changed in hal (Ubuntu):
importance: Medium → Low

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

Changed in hal (Ubuntu):
status: Triaged → Won't Fix
Martin Pitt (pitti) wrote :

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.

Changed in devicekit-disks (Ubuntu):
status: Triaged → Won't Fix
Dana Goyette (danagoyette) wrote :

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?)

Martin G Miller (mgmiller) wrote :

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.

Jamin W. Collins (jcollins) wrote :

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.

Andreas Ntaflos (daff) on 2010-01-11
description: updated
Martin Pitt (pitti) wrote :

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

affects: devicekit-disks (Ubuntu) → udisks (Ubuntu)
Changed in udisks (Ubuntu):
status: Won't Fix → Triaged
Changed in hal:
importance: Unknown → Medium
status: Confirmed → Fix Released

Attaching kernel patch to export the AHCI external port bit.

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
tags: added: patch
Andy Whitcroft (apw) wrote :

@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>

Dana Goyette (danagoyette) wrote :

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

Phillip Susi (psusi) wrote :

@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.

Changed in hal:
importance: Medium → Unknown
Changed in hal:
importance: Unknown → Medium
Changed in linux:
importance: Unknown → Medium
Steve Conklin (sconklin) wrote :

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

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Phillip Susi (psusi) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Triaged
Shang Wu (shangwu) on 2011-06-20
Changed in oem-priority:
importance: Undecided → Medium
Chris Van Hoof (vanhoof) on 2011-06-20
Changed in oem-priority:
assignee: nobody → Chris Van Hoof (vanhoof)
status: New → Confirmed
Chris Van Hoof (vanhoof) on 2011-07-11
Changed in udisks (Ubuntu):
importance: Low → Medium
assignee: nobody → Ayan George (ayan)

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.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix

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.

James M. Leddy (jm-leddy) wrote :

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

Ayan George (ayan) on 2011-11-21
Changed in udisks (Ubuntu):
status: Triaged → Won't Fix
Ayan George (ayan) wrote :

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.

Phillip Susi (psusi) wrote :

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.

Ayan George (ayan) wrote :

@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.

Daniel van Vugt (vanvugt) wrote :

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

Ayan George (ayan) on 2011-11-22
Changed in udisks (Ubuntu):
status: Won't Fix → Incomplete
Changed in oem-priority:
status: Confirmed → Won't Fix
Phillip Susi (psusi) wrote :

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.

Changed in udisks (Ubuntu):
status: Incomplete → Triaged
summary: - External SATA (eSATA) removable disk detected as system-internal
+ External SATA (eSATA) removable disk not auto mounted
Phillip Susi (psusi) on 2011-11-23
description: updated
Chris Van Hoof (vanhoof) on 2011-11-23
Changed in udisks (Ubuntu):
assignee: Ayan George (ayan) → nobody
neutrico (neutrico) wrote :

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.

James M. Leddy (jm-leddy) wrote :

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).

bitinerant (bitinerant) wrote :

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.

David Clayton (dcstar) wrote :

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.

Dale Walker (dale303w) wrote :

@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.

mirak (mirak-mirak) wrote :

I have this issue in Ubuntu Quantal 12.10

Phillip Susi (psusi) wrote :

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.

Phillip Susi (psusi) on 2015-04-20
affects: udisks (Ubuntu) → udisks2 (Ubuntu)
spring (freedaaam) wrote :

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!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.