19

We're trying to mount a disk, but even though the mount command finishes successfully, the disk isn't mounted

bart@test:/$ sudo mount -v /data
mount: /dev/sdc1 mounted on /data.
bart@test:/$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.4G     0  3.4G   0% /dev
tmpfs           697M  688K  697M   1% /run
/dev/sda1        29G  3.0G   26G  11% /
tmpfs           3.5G     0  3.5G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.5G     0  3.5G   0% /sys/fs/cgroup
/dev/sda15      105M  3.4M  102M   4% /boot/efi
/dev/sdb1        14G   41M   13G   1% /mnt
tmpfs           697M     0  697M   0% /run/user/1000

Here is the relevant line in /etc/fstab:

UUID=f7c675d9-6b7c-4f96-a26f-5991df9b7cac    /data   ext4   defaults 1   2

Any idea what we could be missing?

/data is an empty folder with root permissions.

Output of blkid:

/dev/sdb1: UUID="7e15008f-4654-4f1d-8aec-1f233c68e5ea" TYPE="ext4" PARTUUID="3dbf34a8-01"
/dev/sda1: LABEL="cloudimg-rootfs" UUID="21b294f1-25bd-4265-9c4e-d6e4aeb57e97" TYPE="ext4" PARTUUID="bcf3ccb8-bce6-4498-93fb-1b9bd59fc81c"
/dev/sda15: LABEL="UEFI" UUID="5CC4-10AB" TYPE="vfat" PARTUUID="ee783a1a-c5d0-42d9-b874-71796971f49b"
/dev/sda14: PARTUUID="2081abbc-a4ba-496a-b391-07952095f65d"
/dev/sdc1: UUID="f7c675d9-6b7c-4f96-a26f-5991df9b7cac" TYPE="ext4" PARTUUID="54aa8864-01"

[Solved]: So while we tried this very thing multiple times yesterday, we just executed a reboot, and now the device is there. It probably got fixed by changes we made by pointers in this post. I don't know why it required a reboot, but all is good now.

8
  • 1
    What happens if you remove nofail from the fstab line? Commented Oct 11, 2018 at 7:32
  • Could you paste output of blkid ?
    – mrc02_kr
    Commented Oct 11, 2018 at 7:36
  • @StephenKitt that doesn't make a difference unfortunately Commented Oct 11, 2018 at 7:37
  • @mrc02_kr I've added the output to the post Commented Oct 11, 2018 at 7:38
  • 1
    you could try checking journalctl -b. if systemd thinks the device does not exist / is removed, it has a mis-feature where it will unmount the disk. i guess you could also check systemctl list-units *.device and see if there is a systemd device unit for /dev/sdc1.
    – sourcejedi
    Commented Oct 11, 2018 at 7:43

3 Answers 3

28

The most likely reason is that file system is mounted, as the mount commands reports, but then systemd thinks it knows better and unmounts it before you can see it.

You could use another directory as a mount point, or find out from the logs why it is unmounted.

5
  • 14
    So true, It got fixed by systemctl daemon-reexec. How dare systemd make such assumptions and decide to do something? That's why enterprise grade distributions should stop supporting it as the only available init daemon. Commented Jan 5, 2021 at 22:28
  • 1
    Oh god, thank you, this was my case too. systemd is too smart... Commented Apr 7, 2021 at 11:59
  • This helped in my case too, on Raspberry PI OS.
    – DiDiev
    Commented Dec 13, 2021 at 9:54
  • 1
    This would be a lot more interesting if you had any explanation of what the problem actually was.
    – EML
    Commented Jan 24 at 13:26
  • @EML True. But the ways of systemd are mysterious and beyond mere mortals.
    – RalfFriedl
    Commented Jan 24 at 16:39
2

In my case, after the volume successfully mounted, systemd was immediately unmounting it for me (thanks to RalfFriedl for his answer which gave me the hint I needed). This was verifying by running journalctl -f and mounting the volume, and observing the log.

The fix was to add the volume to the /etc/fstab file and then reboot. systemd will adjust itself at boot time based on the fstab file, so it will no longer unmount your volume. Note that you can configure mounts directly in systemd, but the /etc/fstab is the correct place for humans to do it:

Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). 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. For tooling, writing mount units should be preferred over editing /etc/fstab. See systemd-fstab-generator(8) for details about the conversion from /etc/fstab to mount units.

My /etc/fstab entry. Your UUID will surely be different:

UUID=5ffa5f54-6ff0-47dd-97f8-b3446d58b239    /mnt    ext4 
   defaults,noatime,nofail    0    2
0

When you run into this issue on the ZFS filesystem, there is a workaround:

zfs set org.openzfs.systemd:ignore=on tank/your/dataset
systemctl daemon-reload

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .