Most of the time, if I plug a USB drive into my computer, gnome/centos/whatever will ask me what I want to do with it. With a Hitachi Lifestudio, all the partitions mount without asking me.
How do I stop that behavior?
My suspicion is that the same kind of mechanism is what makes candy drops work. So far as I know, my backup drive is not candy, but I would still like to be able to control my computer.
On Wed, Aug 12, 2015 at 03:34:53PM -0500, Michael Hennebry wrote:
Most of the time, if I plug a USB drive into my computer, gnome/centos/whatever will ask me what I want to do with it. With a Hitachi Lifestudio, all the partitions mount without asking me.
How do I stop that behavior?
My suspicion is that the same kind of mechanism is what makes candy drops work. So far as I know, my backup drive is not candy, but I would still like to be able to control my computer.
Not sure, but if you made entries for it in /etc/fstab that explicitly said not to mount, that might do the trick.
It looks as if the "noauto" option should do the trick.
Fred
On Wed, 12 Aug 2015, Fred Smith wrote:
On Wed, Aug 12, 2015 at 03:34:53PM -0500, Michael Hennebry wrote:
Most of the time, if I plug a USB drive into my computer, gnome/centos/whatever will ask me what I want to do with it. With a Hitachi Lifestudio, all the partitions mount without asking me.
How do I stop that behavior?
Not sure, but if you made entries for it in /etc/fstab that explicitly said not to mount, that might do the trick.
It looks as if the "noauto" option should do the trick.
That might work. I could add 30 entries to fstab: /dev/sd[cde][1-9]
My suspicion is that whatever is mounting the drive is treating it special and might ignore fstab. Ideally I'd learn the the name of the automounter and what database to edit.
Michael Hennebry wrote:
On Wed, 12 Aug 2015, Fred Smith wrote:
On Wed, Aug 12, 2015 at 03:34:53PM -0500, Michael Hennebry wrote:
Most of the time, if I plug a USB drive into my computer, gnome/centos/whatever will ask me what I want to do with it. With a Hitachi Lifestudio, all the partitions mount without asking me.
How do I stop that behavior?
Not sure, but if you made entries for it in /etc/fstab that explicitly said not to mount, that might do the trick.
It looks as if the "noauto" option should do the trick.
That might work. I could add 30 entries to fstab: /dev/sd[cde][1-9]
My suspicion is that whatever is mounting the drive is treating it special and might ignore fstab. Ideally I'd learn the the name of the automounter and what database to edit.
autofs is what's mounting it. But if you turn it off, you'll have to manually mount anything that's not in /etc/fstab.
Sounds like gnome's trying to be WinDoze....
mark
On Aug 12, 2015, at 5:22 PM, m.roth@5-cent.us wrote:
autofs is what's mounting it. But if you turn it off, you'll have to manually mount anything that's not in /etc/fstab.
Sounds like gnome's trying to be WinDoze....
Its not ‘autofs’ specifically (which is a simple thing) but udev talking to udisks, allowing your login session to use udisks to mount the volumes if allowed by PolicyKit, speaking through dbus.
Yeah.
-- Jonathan Billings billings@negate.org
On Wed, 12 Aug 2015, Jonathan Billings wrote:
On Aug 12, 2015, at 5:22 PM, m.roth@5-cent.us wrote:
autofs is what's mounting it. But if you turn it off, you'll have to manually mount anything that's not in /etc/fstab.
Sounds like gnome's trying to be WinDoze....
Its not ‘autofs’ specifically (which is a simple thing) but udev talking to udisks, allowing your login session to use udisks to mount the volumes if allowed by PolicyKit, speaking through dbus.
How do I get the ask-first behavior? How do I tell what makes Lifestudio special? When I plug in an SD card through a USB adapter, something asks what I want to do and lists options.
In case it helps: [root@localhost sata400-12-homes]# find / -name '*autofs*' /lib/modules/2.6.32-504.3.3.el6.x86_64/kernel/fs/autofs4 /lib/modules/2.6.32-504.3.3.el6.x86_64/kernel/fs/autofs4/autofs4.ko /lib/modules/2.6.32-504.23.4.el6.x86_64/kernel/fs/autofs4 /lib/modules/2.6.32-504.23.4.el6.x86_64/kernel/fs/autofs4/autofs4.ko /lib/modules/2.6.32-573.1.1.el6.x86_64/kernel/fs/autofs4 /lib/modules/2.6.32-573.1.1.el6.x86_64/kernel/fs/autofs4/autofs4.ko /lib/modules/2.6.32-504.8.1.el6.x86_64/kernel/fs/autofs4 /lib/modules/2.6.32-504.8.1.el6.x86_64/kernel/fs/autofs4/autofs4.ko /lib/modules/2.6.32-504.16.2.el6.x86_64/kernel/fs/autofs4 /lib/modules/2.6.32-504.16.2.el6.x86_64/kernel/fs/autofs4/autofs4.ko /.autofsck /usr/lib/python2.6/site-packages/sos/plugins/autofs.pyo /usr/lib/python2.6/site-packages/sos/plugins/autofs.py /usr/lib/python2.6/site-packages/sos/plugins/autofs.pyc [root@localhost sata400-12-homes]#
Am 13.08.2015 um 19:52 schrieb Michael Hennebry hennebry@web.cs.ndsu.nodak.edu:
On Wed, 12 Aug 2015, Jonathan Billings wrote:
On Aug 12, 2015, at 5:22 PM, m.roth@5-cent.us wrote:
autofs is what's mounting it. But if you turn it off, you'll have to manually mount anything that's not in /etc/fstab. Sounds like gnome's trying to be WinDoze....
Its not ‘autofs’ specifically (which is a simple thing) but udev talking to udisks, allowing your login session to use udisks to mount the volumes if allowed by PolicyKit, speaking through dbus.
How do I get the ask-first behavior? How do I tell what makes Lifestudio special? When I plug in an SD card through a USB adapter, something asks what I want to do and lists options.
Could you provide more context information? Appliance setup, Dekstop setup, server setup? There exist a lot scenarios where something happen automagically?
-- LF
On Thu, Aug 13, 2015 at 12:52:26PM -0500, Michael Hennebry wrote:
On Wed, 12 Aug 2015, Jonathan Billings wrote:
Its not ‘autofs’ specifically (which is a simple thing) but udev
talking to udisks, allowing your login session to use udisks to mount the volumes if allowed by PolicyKit, speaking through dbus.
How do I get the ask-first behavior? How do I tell what makes Lifestudio special? When I plug in an SD card through a USB adapter, something asks what I want to do and lists options.
In case it helps: [root@localhost sata400-12-homes]# find / -name '*autofs*' /lib/modules/2.6.32-504.3.3.el6.x86_64/kernel/fs/autofs4
As I said earlier, this behavior isn't autofs. Don't blame autofs. autofs is a nice tool. autofs is easy to understand, enable and disable.
To disable the auto-mounting of USB disks via udisks, you'd need to set up a custom udev rule. Of course, it's hard to know which existing udev rule is catching your disk, as you said, behavior is different with an SD card than with a USB disk.
For CentOS6, the udev configuration for udisks is: /lib/udev/rules.d/80-udisks.rules
... while in CentOS7, the udisks2 udev config is: /usr/lib/udev/rules.d/80-udisks2.rules
You'd put the custom rule in /etc/udev/rules.d/.
These rules depend on the device name, vendor and model ID, drivers used, etc. You'd have to write a custom udev rule either for that particular device, or something more generic for that class of device.
You might want to consider just disabling udisks{,2} entirely, if you don't use the features.
On Thu, 13 Aug 2015, Leon Fauster wrote:
Could you provide more context information? Appliance setup, Dekstop setup, server setup? There exist a lot scenarios where something happen automagically?
It's a Chimera Desktop 2014. More specifically, I bought the case, the motherboard, the CPU, the RAM and the graphics card from another poster for the price of postage. They'd been in or on their way to the trash. I don't remember whether the DVD writer and the power supply were included. The two hard drives and the floppy drive are transplants from its predecessor. The monitor is of the same vintage. It's running gnome on CentOS 6. My current machine and its predecessor were mentioned in a previous thread.
On Thu, 13 Aug 2015, Jonathan Billings wrote:
To disable the auto-mounting of USB disks via udisks, you'd need to set up a custom udev rule. Of course, it's hard to know which existing udev rule is catching your disk, as you said, behavior is different with an SD card than with a USB disk.
For CentOS6, the udev configuration for udisks is: /lib/udev/rules.d/80-udisks.rules
... while in CentOS7, the udisks2 udev config is: /usr/lib/udev/rules.d/80-udisks2.rules
You'd put the custom rule in /etc/udev/rules.d/.
These rules depend on the device name, vendor and model ID, drivers used, etc. You'd have to write a custom udev rule either for that particular device, or something more generic for that class of device.
I've been trying to read 80-udisks.rules with little success. Would posting it (242 lines) be helpful? After I plug in a drive, is there a way to discover what udev rule was applied?
On Fri, 2015-08-14 at 12:39 -0500, Michael Hennebry wrote:
On Thu, 13 Aug 2015, Leon Fauster wrote:
Could you provide more context information? Appliance setup, Dekstop setup, server setup? There exist a lot scenarios where something happen automagically?
It's a Chimera Desktop 2014. More specifically, I bought the case, the motherboard, the CPU, the RAM and the graphics card from another poster for the price of postage. They'd been in or on their way to the trash. I don't remember whether the DVD writer and the power supply were included. The two hard drives and the floppy drive are transplants from its predecessor. The monitor is of the same vintage. It's running gnome on CentOS 6. My current machine and its predecessor were mentioned in a previous thread.
On Thu, 13 Aug 2015, Jonathan Billings wrote:
To disable the auto-mounting of USB disks via udisks, you'd need to set up a custom udev rule. Of course, it's hard to know which existing udev rule is catching your disk, as you said, behavior is different with an SD card than with a USB disk.
For CentOS6, the udev configuration for udisks is: /lib/udev/rules.d/80-udisks.rules
... while in CentOS7, the udisks2 udev config is: /usr/lib/udev/rules.d/80-udisks2.rules
You'd put the custom rule in /etc/udev/rules.d/.
These rules depend on the device name, vendor and model ID, drivers used, etc. You'd have to write a custom udev rule either for that particular device, or something more generic for that class of device.
I've been trying to read 80-udisks.rules with little success. Would posting it (242 lines) be helpful? After I plug in a drive, is there a way to discover what udev rule was applied?
udevadm test /sys/<device_path>
should give you a whole lot of output. This will include info about what rules apply to the device and actions that udev would take.
On Fri, 14 Aug 2015, Jason Warr wrote:
On Fri, 2015-08-14 at 12:39 -0500, Michael Hennebry wrote:
I've been trying to read 80-udisks.rules with little success. Would posting it (242 lines) be helpful? After I plug in a drive, is there a way to discover what udev rule was applied?
udevadm test /sys/<device_path>
should give you a whole lot of output. This will include info about what rules apply to the device and actions that udev would take.
I did it twice, once with a USB SD card reader and once with another USB drive I discovered that the mount without asking behavior is not specific to Hitachi.
Both experiments produced more than two hundred lines of output. Interpretation escapes me. I expect that posting them here would be considered rude. I did a grep -n apply on both of them.
I did the test on the SD card reader while the what-to-do popup was visible: 98:udev_rules_apply_to_event: RUN 'socket:/org/kernel/dm/multipath_event' /lib/udev/rules.d/40-multipath.rules:16 99:udev_rules_apply_to_event: LINK 'block/8:33' /lib/udev/rules.d/50-udev-default.rules:3 100:udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:76 110:udev_rules_apply_to_event: OWNER 0 /etc/udev/rules.d/60-libsane.rules:3 111:udev_rules_apply_to_event: GROUP 100 /etc/udev/rules.d/60-libsane.rules:3 112:udev_rules_apply_to_event: MODE 0664 /etc/udev/rules.d/60-libsane.rules:3 114:udev_rules_apply_to_event: LINK 'disk/by-id/usb-Generic_STORAGE_DEVICE_000000009451-0:0-part1' /lib/udev/rules.d/60-persistent-storage.rules:55 115:udev_rules_apply_to_event: LINK 'disk/by-path/pci-0000:00:02.1-usb-0:9:1.0-scsi-0:0:0:0-part1' /lib/udev/rules.d/60-persistent-storage.rules:76 116:udev_rules_apply_to_event: IMPORT '/sbin/blkid -o udev -p /dev/sdc1' /lib/udev/rules.d/60-persistent-storage.rules:90 125:udev_rules_apply_to_event: LINK 'disk/by-uuid/3DBE-2637' /lib/udev/rules.d/60-persistent-storage.rules:100 126:udev_rules_apply_to_event: RUN 'udev-acl --action=$env{ACTION} --device=$env{DEVNAME}' /lib/udev/rules.d/70-acl.rules:53 127:udev_rules_apply_to_event: IMPORT 'fstab_import sdc1 block/8:33 disk/by-id/usb-Generic_STORAGE_DEVICE_000000009451-0:0-part1 disk/by-path/pci-0000:00:02.1-usb-0:9:1.0-scsi-0:0:0:0-part1 disk/by-uuid/3DBE-2637 mapper/' /lib/udev/rules.d/79-fstab_import.rules:1 150:udev_rules_apply_to_event: IMPORT 'udisks-part-id /dev/sdc1' /lib/udev/rules.d/80-udisks.rules:87 182:udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
I did the test on the other after all the partitions had been mounted. Not much choice: 98:udev_rules_apply_to_event: RUN 'socket:/org/kernel/dm/multipath_event' /lib/udev/rules.d/40-multipath.rules:16 99:udev_rules_apply_to_event: LINK 'block/8:34' /lib/udev/rules.d/50-udev-default.rules:3 100:udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:76 110:udev_rules_apply_to_event: OWNER 0 /etc/udev/rules.d/60-libsane.rules:3 111:udev_rules_apply_to_event: GROUP 100 /etc/udev/rules.d/60-libsane.rules:3 112:udev_rules_apply_to_event: MODE 0664 /etc/udev/rules.d/60-libsane.rules:3 114:udev_rules_apply_to_event: LINK 'disk/by-id/usb-WD_1200BB_External_57442D5743414C4B31343036323635-0:0-part2' /lib/udev/rules.d/60-persistent-storage.rules:55 115:udev_rules_apply_to_event: LINK 'disk/by-path/pci-0000:00:02.1-usb-0:9:1.0-scsi-0:0:0:0-part2' /lib/udev/rules.d/60-persistent-storage.rules:76 116:udev_rules_apply_to_event: IMPORT '/sbin/blkid -o udev -p /dev/sdc2' /lib/udev/rules.d/60-persistent-storage.rules:90 124:udev_rules_apply_to_event: LINK 'disk/by-uuid/f9bda2dd-8e62-4493-a612-3582f8e639f5' /lib/udev/rules.d/60-persistent-storage.rules:100 125:udev_rules_apply_to_event: RUN 'udev-acl --action=$env{ACTION} --device=$env{DEVNAME}' /lib/udev/rules.d/70-acl.rules:53 126:udev_rules_apply_to_event: IMPORT 'fstab_import sdc2 block/8:34 disk/by-id/usb-WD_1200BB_External_57442D5743414C4B31343036323635-0:0-part2 disk/by-path/pci-0000:00:02.1-usb-0:9:1.0-scsi-0:0:0:0-part2 disk/by-uuid/f9bda2dd-8e62-4493-a612-3582f8e639f5 mapper/' /lib/udev/rules.d/79-fstab_import.rules:1 149:udev_rules_apply_to_event: IMPORT 'udisks-part-id /dev/sdc2' /lib/udev/rules.d/80-udisks.rules:87 194:udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
As before, interpretation escapes me.
-
Fred Smith -
Jason Warr -
Jonathan Billings -
Leon Fauster -
m.roth＠5-cent.us -
Michael Hennebry