1

I'm running Kubuntu 12.04 with KDE 4.11.1. I have a 2TB hard drive mounted in an external USB enclosure. The drive label is Backup. The drive is not automatically mounted when I boot. There are two ways I wish to mount it:

  1. I have a root cron entry that will mount the drive if it is not already mounted. This is part of my nightly backup script.
  2. As a normal user, I can click the drive label in Dolphin's Places panel and the drive will be mounted.

Previously, the drive would mount at /media/Backup in both cases.

I manually created the directory /media/Backup previously and it still exists. The directory is required so that my backup script can mount this disk before the backup runs. As I said, this was working as intended before some recent system updates. I want the drive to mount at the same location in both the situations above.

However, with recent system updates (apparently the LTS Raring HWE stack) the drive mounts at /media/myusername/Backup from Dolphin if I mount it from Dolphin as a normal user. It mounts as /media/root/Backup if I mount it as root user.

There are a variety of ways this new Ubuntu scheme can fail under my scenario. In fact, it is rountinely failing and my nightly backups are not happening anymore. I won't list all the ways I have seen it fail in my troubleshooting so far. I would simply like to restore the previous behavior for this disk or achieve something that works reliably under the new system. Specifically, what I would like to see is:

  1. the drive isn't mounted at boot and isn't mounted unless/until needed.
  2. whether mounted by my normal user via Dolphin or via a script run as root, the drive is always mounted at the same place (so my backup script can find it).
  3. if the drive hasn't been mounted yet (i.e., via Dolphin), my backup script (run as root) is able to mount it at the intended location and then proceed with the backup.
  4. file permissions on files and directories on the mounted drive work as expected

Here's all I needed in my root crontab previously. I'd like to get this working again.

00 03 * * * mount -L Backup /media/Backup >> /var/log/backup.log
05 03 * * * /opt/storeBackup/bin/storeBackup.pl -f /configfile

I prefer not to change my system-wide default behavior. Therefore, this solution doesn't seem ideal: https://askubuntu.com/a/276670/36661 (and I don't yet know if I have the udisk version that would support that solution).

I would appreciate comments on this possible solution: https://askubuntu.com/a/350399/36661

  • Write programming to make it work the way you want. Isn't that part of the beauty of Linux/UNIX systems, if it doesn't work the way you want to program what you want. In windows, you have no option, its a take it or leave it proposition. – mdpc Aug 29 '13 at 1:41
  • Are you mounting by UUID or by Label? – Takkat Aug 29 '13 at 8:05
  • I prefer to mount by Label for my desired solution. But I experimented with mounting by UUID also. That doesn't meet my present needs as well as using Labels. – MountainX for Monica Cellio Sep 24 '13 at 20:34
  • 1
    What you are experiencing is due to a change in automount policy in the udisks2 configuration, I think - see this previous question for possible solutions (the UDISKS_FILESYSTEM_SHARED udev parameter looks like the 'right' way to do it, but I have not tested it) --> askubuntu.com/questions/214646/… – steeldriver Sep 24 '13 at 20:40
  • @steeldriver-thanks for the link. I read all the answers. I'm not sure any of them will work for me. I'll study them in more detail. However, I'd rather not make system-wide changes. I just want to solve this issue for my backups. Other devices can mount under the new /media/<username>/ scheme and that's OK. – MountainX for Monica Cellio Sep 24 '13 at 20:51
1

I have given this answer, which may be the best approach. However, there is also a simpler solution based on the new default behavior of udisks2. Ubuntu's switch from udisks1 to udisks2 is what initially caused my problem. Rather than reverting to the udisks1 behavior, I found a way to use the new default behavior to my advantage.

The key to the solution is that both of the following mounts (for the same device) can co-exist:

  • /media/myusername/Backup
  • /media/root/Backup

Therefore, if I change my backup scripts to use /media/root/Backup and to always mount the device at that location before the backup, my issue is solved. I can continue to use Dolphin the way I do now and I can live with the default (non-root) mount location of /media/myusername/Backup. They do not appear to conflict with each other.

I was striving to avoid having two mounts for one device, but after testing this option I find that it seems to work fine. It solves the backup problems I was seeing.

Unless anyone knows of problems from this approach it may be my preferred approach because it doesn't change the new default behavior, it doesn't rely on any scripts (which always require maintenance over time) and it assures that my backup will not fail due to the device not being mounted.

0

It sounds like you have a leftover mount folder that didn't get deleted properly. With the drive unplugged, run this command from the terminal:

sudo rmdir /media/Backup

Next time you connect your external hard drive, it should mount to the new place. Note that newer versions of Ubuntu will mount to /media/username/Backup instead of /media/Backup

  • I created the directory /media/Backup and it needs to be there so that my backup script can mount the disk before the backup runs. Without the directory, the mount command fails. This (both manual mounting and Dolphin's more automatic mounting) was working correctly before I switched out the full disk. – MountainX for Monica Cellio Aug 29 '13 at 6:26
  • I revised my question based on recent system updates. The problem changed, but it did not get resolved. – MountainX for Monica Cellio Sep 22 '13 at 17:17
0

you can add an entry for the HDD/Partitions in /etc/fstab then it will always be mounted as you need it to.

For more info look on this documentation.

  • That wouldn't solve anything if it is an external HDD that is not always there at boottime – rubo77 May 4 '14 at 11:32
  • @rubo77 this will work always if the device files created for a hdd/partition is always same. mostly if you connect the same hdd to same pc without connecting any other hdd or storage device, system creates same device files for the devices you connect. but this may mess up if you connect a new identical device. these entries will mount the new device to older entries. You can take this approach as a hack. – bikram990 May 5 '14 at 4:03
  • @rubo77 and boot time doesn't effect this as while mounting the hdd system first looks in this file – bikram990 May 5 '14 at 4:05
0

I think the best approach may be this script originating from a SuperUser discussion:
https://github.com/fatso83/Code-Snippets/tree/master/system-utils/ubuntu/automount

I like this approach because it has been debugged and tested fairly extensively (and is known to work on the version of Ubuntu I'm running).

Furthermore, I share the sentiment of the original questioner at SuperUser:

I don't want to have to enter all the data into fstab, partially because it's tedious and annoying, but mostly because I can't predict what I'll be plugging into it or how the partitions will change in the future.

Here's the readme file for the set of scripts:

Auto-mount and unmount usb disks based on disk labels

These scripts are basically ripped from several answers on StackOverflow. The information was spread over several answers, and some were a bit outdated, so I tried to compile all the information and put it here.

The scripts have been found to be working on Ubuntu 10.10 and 12.04.2 LTS If they do not work for you, try to see if there are tips in the original SO discussion (see below). You can then pass me that info, and maybe I will integrate it into a specific patch.

All scripts are to be put in /usr/local/sbin
The udev rules are to be put in /etc/udev/rules.d/

For reference, all info was ripped from here.

  • Has this been tested in 14.04 already? – rubo77 May 4 '14 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.