Auto-mounted external USB drives with Linux autofs daemon

This explains how to use 'autofs' to automatically mount external USB hard drives at a predictable path under CentOS 6 (but probably also works for CentOS 5, RHEL 5, RHEL 6, etc.). On one of my Ubuntu desktops; file systems on USB drives get automatically mounted, but that requires a GUI environment to be installed. On our servers at work, we generally do not install a GUI environment. We also had some special requirements in order to use the USB drives as backup targets:

• The USB drive needs to mount at a standard location. Such as /mnt/offsite/LABEL or something. This way the backup scripts are not overly complex.
• Mounting needs to be automatic, without any user intervention.
• Ideally, the file system should be dismounted when not in use. That way the user who swaps out the backup drives only needs to check the drive activity light before knowing that it is safe to swap out the drive.

So the standard Ubuntu method of doing things via Gnome comes close, but I explored other options as well. The one I settled on is called 'autofs'. It is a script/daemon that is found in the standard CentOS 6 repositories, so you just need to run "yum install autofs".

Configuration of the autofs daemon consists of two parts:

A. You need to find and edit the master configuration file for autofs, also called the 'master map file'. Under CentOS 6, this is located at /etc/auto.master, or you can look at '/etc/sysconfig/autofs ' to find out the configuration file location.

If you want to mount your USB backup drives at /mnt/offsite/XYZ, then your auto.master file only needs to contain the following:

# USB backup drives
/mnt/offsite            /etc/auto.offsite       --timeout=1800

As you can see, you tell autofs the location, what configuration file to look at for devices that need to be mounted, and optional arguments such as custom timeout settings. Note that you need to create the location directory by hand (e.g. "# mkdir /mnt/offsite") before starting autofs.

B. The second part of configuration is telling autofs which devices should be automatically mounted. It is best if you use either the UUID of the partition (/dev/disk/by-uuid/XYZ) or the device ID (/dev/disk/by-id/XYZ-part0).

OFFSITE1 -fstype=ext4,rw,noatime,data=journal,commit=1 
    :/dev/disk/by-uuid/b5c1db0d-776f-499b-b4f2-ac53ec3bf0ef

Please note that the above should be all on line line, I have broken it up for clarity.

The only real mount options that you need is "fstype=auto,rw,noatime". I have added "data=journal,commit=1" to make the ext4 file system on the drive a bit more resilient.

One limitation of autofs is that if you have multiple USB drives to be mounted, each one needs its own unique mount point (/mnt/offsite/OFFSITE1, /mnt/offsite/OFFSITE2, etc.). However, you could decide to mount all of the drives at the same location if you give them all the same UUID. But I'm not sure how well autofs would deal with two drives, having the same UUID, being hooked up to the server at the same time.

---

After editing your mapping file, you (probably) need to restart autofs. Assuming that you have done everything correctly, attempting to list the contents 'ls -l /mnt/offsite/OFFSITE1' will cause the drive to be automatically mounted. After the timeout period expires, the drive will automatically dismount.

Updates (2015):

I have started to document this process in my "sync2usb" project over on GitHub.  Including using LUKS encryption to protect the contents of the USB drive against disclosure after loss/theft.

https://github.com/tgharold/sync2usb/blob/master/AUTOFS.md
https://github.com/tgharold/sync2usb/blob/master/LUKS.md

Unsupported sector size 520

While setting up a new DIY server using 15k RPM SAS drives, I ran across some drives which came from the factory with 520 byte sectors (oops).  You'll be able to hook them up and see that they show up as /dev/sdX, but you won't be able to do anything with them (such as read/write or partition).

If you look in /var/log/messages, you will see useful information:

Mar  9 08:08:54 vhc-carthage kernel: sd 6:0:7:0: [sdh] Attached SCSI disk
Mar  9 08:08:57 vhc-carthage kernel: ...ready
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Unsupported sector size 520.
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] 0 512-byte logical blocks: (0 B/0 B)
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] 520-byte physical blocks
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Write Protect is off
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Write cache: disabled, read cache: enabled, supports DPO and FUA
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Unsupported sector size 520.
Mar  9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Attached SCSI disk

The fix for this is pretty simple in RHEL6/CentOS6.  Major pointers for this came from PissedOffAdmins.

# yum install sg3_utils

# sg_scan -i
/dev/sg8: scsi6 channel=0 id=7 lun=0
    NETAPP    X287_S15K5288A15  NA00 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg9: scsi6 channel=0 id=8 lun=0
    NETAPP    X287_S15K5288A15  NA00 [rmb=0 cmdq=1 pqual=0 pdev=0x0]

Now you should format the offending drive using the "sg_format" command.

[root@vhc-carthage /]# sg_format --format --size=512 /dev/sg8

    NETAPP    X287_S15K5288A15  NA00   peripheral_type: disk [0x0]
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=573653847 [0x22314357]
  Block size=520 [0x208]

A FORMAT will commence in 10 seconds
    ALL data on /dev/sg8 will be DESTROYED
        Press control-C to abort

After this, the disk should work when connected to a regular SAS controller (in my case, a 16-port LSI).

Final note: You will probably find that the disks which have been converted from 520 byte sectors to 512 byte sectors will not perform as well as a disk that was originally manufactured for use as a 512 byte sector drive.  At least, that has been my experience with a sample size of just two drives (and I don't plan on purchasing the wrong drives again).