Warning: some of the following command-line programs should be run as root and, if wrongly used, can cause harm to the system, loss of data, scaly skin and inchoate baldness. Thus, before doing something foolish (or blaming me) read all the necessary documentation and then proceed.
If you use HAL and one of your external hard drive is not automatically mounted, but you can mount it from command line, maybe your problem is similar to mine.
Let’s check: plug your external hard drive and see what dmesg says:
$ dmesg
[...]
usb 1-8: new high speed USB device using ehci_hcd and address 4
usb 1-8: configuration #1 chosen from 1 choice
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
usb 1-8: New USB device found, idVendor=XXXX, idProduct=XXXX
usb 1-8: New USB device strings: Mfr=XX, Product=XX, SerialNumber=X
usb 1-8: Product: XXXXXXXXXXXXXXXXXX
usb 1-8: Manufacturer: XXXXXX
usb 1-8: SerialNumber: XXXXXXXXXXXX
scsi 3:0:0:0: XXXXXXXXXXXXXX
sd 3:0:0:0: [sdb] XXXXXXXX 512-byte hardware sectors (XXXXXX MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: XX XX XX XX
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sd 3:0:0:0: [sdb] XXXXXXXX 512-byte hardware sectors (XXXXXX MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: XX XX XX XX
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 3:0:0:0: [sdb] Attached SCSI disk
sd 3:0:0:0: Attached scsi generic sg1 type 0
usb-storage: device scan complete
If you see something like the above (obviously you’ll see something else instead of the X) it means that your hardware has been detected. Good.
Now let’s see if the proper messages reach HAL. Unmount and unplug the device, run lshal -m and then plug it back in:
$ lshal -m
Start monitoring devicelist:
-------------------------------------------------
15:32:54.354: usb_device_XXXXXXXXXX added
[...]
15:33:00.244: storage_serial_XXXXXXXXXXX added
15:33:00.276: volume_part1_size_XXXXXXXXXXXXX added
15:38:35.406: usb_device_XXXXXXXXXXX removed
15:38:35.410: volume_part1_size_XXXXXXXXXXXXX removed
15:38:35.416: storage_serial_XXXXXXXXXXX removed
15:38:35.419: usb_device_XXXXXXXXXXX removed
[...]
Here we see that HAL knows whether/when our hard drive is plugged, but our desktop didn’t say (or do) a thing: no popups, no icons, no warnings, no error messages nowhere, not even in the system logs.
From dmesg we know that the hard drive is given the device /dev/sdb, with one partition, /dev/sdb1. Let’s try and mount it:
Or, if the device is not listed in /etc/fstab do (as root):
# mkdir /tmp/disk
# mount -t vfat /dev/sdb1 /tmp/disk
If you succeeded: very good, your system mostly works, there should only be a minor problem somewhere.
Let’s check if there are symbolic links to /dev/sdb1 under /dev/disk/*:
$ ls -l /dev/disk/* | grep sdb1
In my system there were links under /dev/disk/by-id and /dev/disk/by-path. The link under /dev/disk/by-uuid was missing.
Thinking about it, even the output of lshal had something wrong: the “udi” containing the string block.device = '/dev/sdb1' had others void variables; for example: volume.{fstype,label,partition.uuid,uuid}.
I should say that I tried with other external drives, and had no problems. I thought there was something wrong in the filesystem: but mount worked and gave no error. So I checked with dosfsck, and found something: I repaired the errors it found, but there still was something wrong, since automount didn’t work. So I tried parted: it found an error and refused to continue. At last, I ran testdisk: choose the device, choose the Intel partition table, choose analyse. It certified at once: “invalid FAT boot sector”. Good (?) let’s repair it: choose “MBR Code”. It told me both boot sectors were at fault. Let’s rebuild them right away! All done, I could quit from testdisk.
I unplugged my hard drive and plugged it back in: the infamous windows appeared asking me what to do. Problem solved. Uhmmm. Well, it was fun.
/etc/fstab and HAL
If you find somebody claiming that if a device is listed in /etc/fstab, then automount won’t work anymore on that device, disregard him. You can do it, and it can be useful: now you can mount/unmount devices from the command line as a normal user, and they get mounted where you told them to; and you won’t have problems with accented letters (it can happen if you don’t have an utf8 locale and use HAL with a clean fstab to mount a fat32/ntfs filesystem).
You can use this line as an example:
/dev/disk/by-uuid/XXXXXXXX /mnt/XXXXXX vfat noauto,users,umask=000 0 0
(Remember, you have to mkdir /mnt/XXXXXX as root).
NTFS
Most of the above observations should be valid and useful for NTFS too, but I didn’t test.
NTFS-3G: Permission denied
If you get this message while trying to mount an NTFS filesystem with ntfs-3g:
Error opening '/dev/sdb1': Permission denied
Failed to mount '/dev/sdb1': Permission denied
Please check '/dev/sdb1' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
http://ntfs-3g.org/support.html#unprivileged
Then you should begin following the suggestions in: http://ntfs-3g.org/support.html#unprivileged
Let’s have an ntfs-3g ‘setuid root’:
# chmod 4755 /bin/ntfs-3g
Now plug your external hard drive back in. If you still have permissions’ problems, you have to check the device filesystem.
Below you can see permissions of an external hard drive with an NTFS filesystem (/dev/sdb*) and those of an usb pendrive with a FAT32 filesystem (/dev/sdc*). My user belongs to the “plugdev” group, and can thus mount the pendrive with no problems. The external hard drive mounted fine when it was a FAT32 filesystem; maybe udev used a different rule and gave it the ‘plugdev’ group?
brw-rw---- 1 root disk 8, 16 2009-05-16 14:06 /dev/sdb
brw-rw---- 1 root disk 8, 17 2009-05-16 14:06 /dev/sdb1
brw-rw---- 1 root plugdev 8, 32 2009-05-16 14:08 /dev/sdc
brw-rw---- 1 root plugdev 8, 33 2009-05-16 14:08 /dev/sdc1
Let’s change udev rules to do our selfish needs (we want to have /dev/sdb* in the plugdev group). With the help of the guide at:
We search in sysfs:
… here we have /sys/block/sdb. That’s the parameter to feed to the _obvious_ command
# udevadm info --path=/sys/class/block/sdb --attribute-walk|less
Now we can search the device whose group we want to change, and will build rules such as:
ATTRS{vendor}=="VENDOR" ATTRS{model}=="MODEL" GROUP="plugdev"
… and we will put this rule in a file under /etc/udev/rules.d/. For example, in /etc/udev/rules.d/90-local.rules. Note that the _last_ rules override the previous ones: that’s why this file begins with “90”.
With a kernel supporting inotify you won’t have to restart udev, so you can repeat the usual “unplug-plug back” mantra.
If you still have problems with permissions, check /etc/fstab: if you have a rule about this device, you have to make a proper directory where the drive will be mounted and change its permissions.
