On a HAL-free, udisks-1.0.2 system that's up to date, mounting eSATA disks does not work as conveniently as it does for USB drives. This is DE-independent as far as I understand. The problem lies within udisks itself: It cannot determine whether a disk is attached via eSATA (yet). The ebuild and patch that follow solve it nicely for the time until we have full eSATA support. Note however that the kernel/udisks will never be able to detect eSATA disks connected via internal SATA ports (via slot brackets/adapters as Gigabyte for example puts them in their mobo packages). Therefore, this patch might have relevance even after a full eSATA detection in the kernel and udisks. Some references, as it took me 3 days to find all of this: My post, also outlining the HAL solution that has worked before: http://forums.gentoo.org/viewtopic-p-6606395.html#6606395 A bug report regarding the solution that's also present in Gentoo's 80-udisks.rules file that does not seem to work properly: https://bugs.freedesktop.org/show_bug.cgi?id=35354 The original patch: https://bugs.freedesktop.org/show_bug.cgi?id=22879 Reproducible: Always Steps to Reproduce: 1. emerge standard udisks-1.0.2 2. plug in eSATA disk 3. no icon shows up on the desktop (or however your DE does it) Happens on a SiI 3132 in an ExpressCard slot with a naked SATA HD connected via an eSATA adapter.
Created attachment 266123 [details] updated ebuild with patch and manifest udisks-1.0.2 patched to allow overriding a device's "system internal" bit via udev
For the kernel guys: A kernel patch I found that might export the needed port information that udisks could use for handling this more transparently: http://launchpadlibrarian.net/61502151/0001-PATCH-Export-ahci-eSATA-attribute.patch
udisks-1.0.3 makes the modified ebuild obsolete. This is what you have to put in your udev rules for apps to pick up the newly added device as removable (adjust to your controller and HD setup accordingly): KERNEL=="sd[b-z]", ATTRS{class}=="0x060400", ENV{UDISKS_SYSTEM_INTERNAL}="0" still, this should not be necessary to configure anyway..
Is this still a problem with udisks:2 and a recent kernel ?
Facts: .pkla files -> for older than polkit-0.105, in XML format .rules files -> new type of files in JavaScript format Help: Take a look at .rules files inside /usr/portage/net-misc/modemmanager/files/ and /usr/portage/net-misc/networkmanager/files/ You can edit them to say things like org.freedesktop.udisks2.* and org.freedesktop.udisks.* That will give you total control in plugdev also to internal disks, or look inside /usr/share/polkit-1/actions/*udisks* for indivitual permissions to different tasks, like mounting :-) I'd say this is WORKSFORME after that, but lets reconsider after testing if it just works with sys-fs/udisks:2 and gnome-base/gvfs with USE="-gdu udisks udev" even without above instructions.
i don't really have the time to test this now but i'll try to do it asap. however i don't know if gvfs will really be the only thing that will have to pick it up, e.g. i am using e17 so i guess eeze will have to do it. from what i researched initially, my expresscard controller does not export the necessary information of it being external, so i guess there has to be some sort of manual interaction, else the system won't be able to differentiate between internal and external ports...
I still have such issues with KDE and udisks2 using my ThinkPads Ultrabay, second HDD-Adapter (uptodate ~amd64)
Please recheck with udisks-2.1.6 as this won't probably be ever fixed for old slot (it's dead for ages)
