Automounting an attached USB partition in debian 12 minimal

User Support
1

I’m trying to get a partition automounted by adding an entry to /etc/fstab, but it’s not working. I’m not sure if this is because of Qubes, or something else.

On debian minimal 12, I’ve added /etc/fstab to bound-dirs, and added this line:

UUID=<partition-uuid> /mount/point auto defaults,nofail,x-systemd.automount 0 0

then rebooted and attached the partition. The contents of /etc/fstab persist, the partition is seen with lsblk, the UUID is correct and sudo mount -a mounts it. But it doesn’t happen automatically and sudo systemct status '*automount' doesn’t list the unit which was supposed to be created automatically.

2

Hi fb2043 :slight_smile:

What happens, if you (instead of sudo mount -a after a reboot) just do a

cd /mount/point

?

… I’ve not looked into SystemD and automounting – so it’s a question, because I don’t know … :slight_smile:

:slight_smile:

3

The mount point just stays empty.

4

According to systemd.mount(5) — systemd — Debian testing — Debian Manpages :

Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans.

x-systemd.automount

An automount unit will be created for the file system.

5

Is it working with a non-minimal template?

6

No

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

7

I won’t work that way, because bind-dirs is running after system mounted all necessary filesystems from either fstab and systemd.
So it’s too late.
You have 2 options.

  1. add mount command to /rw/config/rc.local
  2. make systemd auto mount on access (this can have idle time after which it will auto unmount)

– 1 –
It’s easier since you have fstab entry already then just edit /rw/config/rc.local and add line at the end:

sudo mount /mount/point

– 2 –
Doing it in template it will start without /rw/config/rc.local, but it will throw errors in journal if block device not present in other appVM’s based on that template.
But if done in appVM with bind-dirs you still need to add some commands do rc.local for it to start systemd services.

Whatever you chose template or appVM/rw you could do it in a way that it just mount on qube start but if device to mount not present during start then it won’t mount anything.
If you do auto mount on request then there will be service running that will auto mount it as soon as you enter inside /mount/point, like open it’s directory in file manager or do ls /mount/point.
Mehod 2 is lenghty with 2 service files to make and some additional commands to make.
But I didn’t made it in debian… is debian qubes have same systemd as fedoras?

8

Good catch! It started working after I edited /etc/fstab in the template.

But this didn’t fully solve the mystery, yet. According to the man page I linked above:

Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded.

So that suggests the automount unit should still be created automatically, if you just run systemctl daemon-reload (and without rebooting). Because at that stage, the bind-dir version of /etc/fstab is already mounted in the AppVM. However, it still didn’t work and I couldn’t see the new automount unit using systemctl status '*automount'.

It turns out that the unit was being created correctly, but it was being left in an inactive state (which I guess is a systemd quirk). I was able to see it eventually using systemctl status -all '*automount'.

So in the end, the solution was to additionally run systemctl start <unit>.automount. Afterwards everything works as expected.

This is the final setup I’m using (all configuration is in an AppVM):

/etc/fstab:

UUID=<partition-uuid> /mount/point auto defaults,nofail,x-systemd.automount,x-systemd.device-timeout=1 0 0

/rw/config/qubes-bind-dirs.d/50_user.conf:

binds+=( /etc/fstab )

/rw/config/rc.local:

systemctl daemon-reload
systemctl start <unit>.automount

To find the string for <unit>, run systemctl status -all '*automount' and look for the one that matches your mount point; it might contain some escaped characters.

Thanks again @KitsuneNoBaka. The breakthrough here came after realising that bound-dirs are not mounted immediately at boot time.

EDIT: Just a heads up that the partition got corrupted soon after I started using this. I put the laptop to sleep without unmounting the partition first; when I resumed the laptop, all the files on the partition (ext4) were gone (it was bad enough that utilities like fsck couldn’t fix it using the superblock backups; photorec could recover the files, but testdisk couldn’t recover the directory structure). I’m not sure if it’s related to the systemd automounting configuration, or just a shitty coincidence. It’s probably related to: Implement facilities for handling unexpected physical removal of block devices · Issue #1082 · QubesOS/qubes-issues · GitHub . Currently discussing alternatives at Having to re-attach USB drive partitions after waking laptop from sleep .

9

Yes, when you reload daemon it will convert fstab to native units, so? Why do you think it would automatically mount during daemon reload? There is target that was run once during boot and now you can only run unit manually or make manually systemd automount unit which mount this mount point when you access it.

10

/etc/fstab with x-systemd.automount option generates an automount unit after daemon-reload, but the unit has the status inactive (dead), so it won’t trigger. If you run systemctl start, the status changes to active (waiting) and it will perform automounting later.

11

Just a heads up that the partition got corrupted soon after I started using this. I put the laptop to sleep without unmounting the partition first; when I resumed the laptop, all the files on the partition (ext4) were gone (it was bad enough that utilities like fsck couldn’t fix it using the superblock backups; photorec could recover the files, but testdisk couldn’t recover the directory structure). I’m not sure if it’s related to the systemd automounting configuration, or just a shitty coincidence. It’s possibly related to: Implement facilities for handling unexpected physical removal of block devices · Issue #1082 · QubesOS/qubes-issues · GitHub . Currently discussing alternatives at Having to re-attach USB drive partitions after waking laptop from sleep .

12

What works for me is attaching the USB device automatically when the qube starts, and then mounting it through a small script that is executed by a systemd user service.

1. Auto-attach the USB device to the qube

First, configure the USB device to automatically attach when the qube starts (using the Qubes USB settings or qvm-usb). This ensures the device is already visible inside the VM.

2. Create a mount script

Create a script in your home directory, for example:

~/mount-disk.sh

#!/bin/bash
sudo mount /dev/sdX1 /mnt/usb

Replace /dev/sdX1 with the correct partition and /mnt/usb with your desired mount point.

Make it executable:

chmod +x ~/mount-disk.sh

3. Create a systemd user service

Create the following file:

~/.config/systemd/user/mount-disk.service

[Unit]
Description=Mount USB disk

[Service]
Type=oneshot
ExecStart=/home/user/mount-disk.sh

[Install]
WantedBy=default.target

4. Enable the service

systemctl --user daemon-reload
systemctl --user enable mount-disk.service

Now, whenever the qube starts and the USB device is auto-attached, the script runs and mounts the partition automatically.

This approach keeps things simple: the USB is attached at startup, and a small script plus a systemd service handles the mounting.

1 Like