USB Automount

Hello there,

First I’m not sure if this functionality is available is DietPi as I’m fairly new to the Pi game.

I’m using Raspberry Pi 3 B+ and just moved from Raspbian to DietPi looking for one partical feature which I got the indication its available in DietPi (I hope I’m right)

I want to automount ANY usb without using the drive manager nor editing fstab anytime I plug in a new drive to my raspberry pi. When I used Raspbian it worked in desktop version but I want this in headless unit. I tried usbmount and pmount and non of them is straight forward nor work perfectly after spending hours setting them up. Using desktop version is not a choice for me as I want to save CPU and RAM power as much as possible.

So is there an easy way to just mount any plugged in usb or hdd similar to desktop systems?

Thanks in advance

The diet-pi drive manager would be your best bet AFAIK. That being said, there may be away to do it in linux but I’m not sure. Using the drive manager is pretty easy and quick to do.

Why are you wanting to connect / reconnect HDD’s all the time? Unplugging the HDD without mounting it is probably no the best idea.

You may have to give more information as to what you are trying to accomplish in order to get more direction from the forums

  • Drew

I think the Drive Manager requires manual setup and I have to choose each new drive manually to mount it as far as I know and I could be wrong.

What I’m trying to achieve is to setup a samba share for my parents (they don’t know how to mount on unmount a drive). So my concept is automount any usb drive plugged in, and then use a drive pool software (MergerFS for example) and this pool will be shared via samba server. The usb sticks they use are not always the same usb sticks for stab entries won’t be a good idea and it’s not practical to manually add every new drive to fstab in this dynamic situation.

In summary, I want to automount ANY usb drive to specific directory with it’s own mount point (maybe it’s label or whatever), and the directory that will contain the mount points for all usbs will have it’s stab entry using MergerFS to pool all of them, and the pool will be shared via samba.

Getting the Drive Manager setup is not too hard, but you’re looking for away to mount / unmount once the drive is plugged in. Maybe if could be done with a button and some GPIO coding?

Push button → button does the work behind the scenes to mount / unmount → possibly play a sound or flash a LED when complete. All of that would require more coding & speaker or an LED(s) Not impossible but out of my league. Sounds like A LOT OF READING and googling. It’s probably not impossible? But like I said it’s out of my league

As for a label for the drive, any external drive that is getting mounted onto the DietPi now uses the UUID by default. I don’t remember what it stands for but it’s an ID that is specific to that hard drive / USB.

Best of luck, hopefully you’ll be able to get it to work. Sorry I wasn’t much help

  • Drew
#apt-get install automount autofs

Insert USB (it should mount it automatically to a directory)

Then type mount and it should list the new usb device as a mount location

just cd into that directory and it should work

DrewG that would be to sophisticated to me as well and totally out of my league, I just started using terminals a month ago and have no clue about scripting! But thanks for the idea, it will be too cool to show off infront of my parents!

WarHawk thanks I will give it a try as soon as I go home!

@ZiryaZiryab, did installing automount & autofs work for you?

I have the same problem, with the programs above i receive: “Unable to locate package automount”

I need the automount feature because Iḿ going to have a backup server at my parent’s home and when fot some reason they have a blackout , when the system is powered again I want it to keep working with the usb mounted.

Maybe my best choice is using fstab adding the hdd usb?

did you solved your problem finaly?

Just checked, and nowadays one should use the usbmount package:

apt install usbmount

Check the Debian wiki for two alternatives, if one wants to have desktop icons created, if a drive is attached.

EDIT: Ah lol no, usbmount is not available on Stretch and Buster:
I just got the above info from the autofs wiki:
But the info about autofs being superseded by usbmount seems to be again outdated :rofl:.

Hmm then autofs should do, although it seems to require some manual configuration?

Further reading: automount is the command provided by the autofs package :wink::

I eventually went with the pmount package and some udev rules. It’s working well. Whichever USB drive I plug in is automatically available as /media/usb1. I documented the process here: (look for the pmount & udev bits, you can ignore the music bits).

Actually I have just installed usbmount, and it works.

But it is necessary to change MountFlags=slave to MountFlags=shared in /lib/systemd/system/systemd-udevd.service

Hi Your link is no longer working! Can you provide a new one?

For me the following worked:
I uninstalled autofs and usbmount cause they seem to conflict to my udev rule which did the job perfectly for me. I want to mount a special USB stick (and only this stick, if it is plugged in, to start a rsync process). So I created a file in udev rules in /etc/udev/rules.d/60-usbstartscript.rules:

#Action when mounting
KERNEL=="sd[a-z][0-9]", ENV{ID_MODEL_ID}=="1a03", ENV{ID_VENDOR_ID}=="1b1c", ACTION=="add", ENV{mount_options}="relatime", RUN+="/bin/mount -o $env{mount_options} /dev/%k /    myUSBdevice"

#Action when unmounting
KERNEL=="sd[a-z][0-9]", ENV{ID_MODEL_ID}=="1a03", ENV{ID_VENDOR_ID}=="1b1c", ACTION=="remove", RUN+="/bin/umount -l /myUSBdevice"

You can find out the relevant Model ID and Vendor id by typing:

$udevadm info -q all -p $(udevadm info -q path -n /dev/sdXY)

in my case /dev/sdb1
After that restart system with

$udevadm control --reload-rules &&udevadm  trigger
$systemctl  daemon-reload

The code here helped me:

At least that worked for me!

That was not the whole solution! It turned out that commands run via RUN+= have only a short limited live and I got soon errors like "Transport endpoint is not connected” and my mount point broke before the script was run succesfully through: So I set up a systemd process which I instead started when hot plugged in:
Script in /etc/systemd/system/myUSBservice@.service

[Unit] to /nextCloud
ExecStart=/root/ -v %I

and in the udev rule file /etc/udev/rules.d/60-usbstartscript.rules:

KERNEL=="sd[a-z][0-9]", ENV{ID_MODEL_ID}=="1a03", ENV{ID_VENDOR_ID}=="1b1c", ACTION=="add", ENV{SYSTEMD_WANTS}="paeddasUSBStickSync@%k.service"

In the related script ( I do the mounting of the device using its UUID and prove if it is already mounted and then rsync all folders to the /nextcloud folder. In the end I umount the device! Now I can rsync my USB device without even connecting to the a bash remotely.

I derived that recipe from the following link and is now tested:

peddanet : here is an updated link, see page 3.

Many thanks for sharing. A systemd unit is btw automatically created when adding an fstab entry and running systemctl daemon-reload. My current idea about implementing automount to DietPi is to add a dietpi-drive_manager command that simply re-scans attached drives, re-creates fstab, does above reload and mounts the given input drive automatically to a reasonable mount point, optionally to the given mount point. Most code/functions for this is already there, hence should be quite simple. E.g. dietpi-drive_manager mount /dev/sda1 or with optional mount point argument: dietpi-drive_manager mount /dev/sda1 /mnt/myData
And: dietpi-drive_manager umount [/dev/sda1|/mnt/myData]

The udev rules would then be same, but the above used as RUN+=. The only thing that I am not sure how to handle yet:

  • If the fstab entry already exist for a device, on boot it will be automounted already, hence the udev rule creates additional overhead or could even conflict with existing systemd mount/automount units.
  • We want all attached drives to be mounted automatically, but actually only after boot schedule has finished and/or those are definitely not in the fstab already. Not sure how to add such a delay or requirement to the udev rule. Ugly workaround would be to move the rule in place at end of boot and remove it on shutdown or better move it to tmpfs and link it from there, so it is assured to be empty/skipped on boot.

Also it would be great if drive manager would remember the chosen mount point. We could leave the fstab entry in place with “noauto” and without x-systemd.automount. When re-creating fstab, we would need to scan for those entries first and re-add them, marked as unmounted or even unplugged. It must then be possible to actively remove those fstab entries. Currently unmounted drives are added commented with fixed mount point to /tmp/ and unplugged drives are removed from fstab when starting/refreshing drive manager, hence the chosen mount point is lost.

Two questions:
What happens on boot (journalctl) when you added this drive to fstab while having the udev rule in place? Do you see the mount being done two times, of the udev rule failing due to already mounted drive?

I am not 100% sure about the umount thing. If the device is removed/unplugged manually, BEFORE unmounting it, this is not failsafe against file corruption anyway. I guess umount would normally throw an error, umount -l seems to be possible and reasonable at least to tell the system that the mount has gone, but actually every drive should be umounted BEFORE removing/unplugging it.

I approached the problem in a very pragmatic way, so unfortunately I do not have deep answers to your question (wish I did). My need is for a USB drive to automount at boot and for those files to be accessible on a known/predictable path. I found the solution in the usual pragmatic way (Google). My pragmatic answer is that the method described has worked very reliably for me and for the small number of users of my Dementia Friendly Music Player. However, that use is in a simple low-stress system, so it is unlikely to reveal subtle issues.

All this said, if Michael provides a better way, I’m happy to beta test and then switch.

If it only needs to mount at boot, then you don’t need all the udev rules thing. Simply add an entry to /etc/fstab or start dietpi-drive_manager, select the drive and select mount.
NB: Non-root/boot file systems are added with noauto,x-systemd.automount options, hence they will not be mounted automatically on boot, but an automount watcher is placed which mounts the drive immediately once anything accesses the mount point. So practically it is like mounted.

All this udev thing is only a topic when its about auto-mounting hotplugged drives, e.g. plugging an USB stick. This would be a great feature but it must not collide/conflict with the on-boot automount since the udev trigger is called on boot as well.

For reference:

Thanks Michael. I’m always looking for simpler / built-in methods. But if I understand your method correctly, it requires a one-time admin intervention per USB stick. I chose the udev route because it needs to work for someone that downloads the SD card image that I created who then uses their own Pi & USB stick in a headless and potentially networkless box.

Okay if there is no interaction (no SSH and no local console) possible, then indeed the generic udev-based automount is the only way. The content is then indeed script/program-based or what? Just thinking what for to mount a USB stick on a machine that is networkless and headless :slight_smile:.

The USB stick has music. The project is The Dementia Friendly Music Player Essentially DietPi + headless VLC + rotary encoders + Python + laser cut bamboo or cherry. DietPi has been consistently excellent for this.

Ah yes totally reasonable then. So regardless of which USB stick is attached, it must be mounted to where the music payer is looking for music. Indeed fstab is not suitable for this and the udev rule totally makes sense.

I’m thinking if we can add this somehow to drive manager as well. E.g. input a device definition or pattern and a fixed mount point. It could then skip these during drive loop to not add them to fstab…

Okay much more ideas then time currently, but I’ll keep this on mind when doing some drive manager rework anyway.