Partition in /etc/fstab not mounted automatically at boot

English Install/Boot/Login
1

Hi All,

I have an entry in /etc/fstab to mount an existing partition to an existing directory

UUID=3aa73beb-9e7b-4220-a6f3-bf084538fc74 /scratch ext4 defaults 0 0

blkid shows the right UUID

/dev/sda4: UUID=“3aa73beb-9e7b-4220-a6f3-bf084538fc74” TYPE=“ext4” PARTUUID=“96e155b6-b5ec-4437-975e-333943eeb41b”

The partition is not mounted when I boot the machine. All system partitions like /boot/efi or /root or /opt are mounted. After booting I have to do a

mount -a

to mount the partition. I can not find any errors in the logs.

Any ideas what might be wrong?

Thank you
Willi

2

I have read this earlier, but by searching the forums I can only find similar about Btrfs subvolumes, not about “normal” file sytems. Well, vaguely I remember also an ext4 case.

In those cases the file system is mounted at boot, but immediatly unmounted again. That can be seen in the loggings though.

Let us wait for others with better memories :wink:

BTW:

There is an important, but not easy to find feature on the forums.

Please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt.

An example is here: Using CODE tags Around your paste.

3

Any consequence if you change to:

UUID=3aa73beb-9e7b-4220-a6f3-bf084538fc74 /scratch ext4 nofail 0 2

???

4

Makes no difference, automatic mount does not work.

The same partitioning works without problems under Debian and Fedora. So, what does Tumbleweed make different?

5

It should work on TW likewise. There is some problem.

Because I remember earlier reports, is your TW up-to-date?

6

I think so


zypper dup
...
Nothing to do.
7

Please show the result of (done directly after system start-up as root in a console)

# journalctl -b 0 | grep mount

Regards

susejunky

8

Re using /scratch, I have no issues with doing just that. However, here is an idea.
umount /scratch
ls -l / and verify the ownership and properties & permissions.

Then do the manual mount and reverify them.

Eventually, because I have separate installations of Suse KDE, SUSE Tumbleweed, and Fedora, I changed the name of my /scratch to /share

But that should not be an issue at all.
Here is my fstab entry with a title header


#<file system>                            <mount>   <type>   <options>                   <dmp pass> <xref>          <label/uuid>
UUID=acefc30a-d7fc-40fb-82c5-e0cae7c85ff0 /share    ext4     defaults,relatime             1  2     #/dev/nvme0n1p5 nvme0n1p5Share
9

Here it is:

Dec 05 07:46:42 sedenko systemd[1]: Condition check resulted in dracut pre-mount hook being skipped.
Dec 05 07:46:44 sedenko systemd[1]: Condition check resulted in dracut mount hook being skipped.
Dec 05 07:46:45 sedenko kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /.snapshots...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /boot/efi...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /boot/grub2/i386-pc...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /boot/grub2/x86_64-efi...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /opt...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /root...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /scratch...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /srv...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /usr/local...
Dec 05 07:46:46 sedenko systemd[1]: Unmounting /tmp...
Dec 05 07:46:46 sedenko systemd[1]: \x2esnapshots.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /.snapshots.
Dec 05 07:46:46 sedenko systemd[1]: boot-efi.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /boot/efi.
Dec 05 07:46:46 sedenko systemd[1]: boot-grub2-i386\x2dpc.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /boot/grub2/i386-pc.
Dec 05 07:46:46 sedenko systemd[1]: boot-grub2-x86_64\x2defi.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /boot/grub2/x86_64-efi.
Dec 05 07:46:46 sedenko systemd[1]: opt.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /opt.
Dec 05 07:46:46 sedenko systemd[1]: root.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /root.
Dec 05 07:46:46 sedenko systemd[1]: scratch.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /scratch.
Dec 05 07:46:46 sedenko systemd[1]: srv.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /srv.
Dec 05 07:46:46 sedenko systemd[1]: usr-local.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /usr/local.
Dec 05 07:46:46 sedenko systemd[1]: tmp.mount: Succeeded.
Dec 05 07:46:46 sedenko systemd[1]: Unmounted /tmp.
Dec 05 07:46:55 sedenko systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Dec 05 07:47:00 sedenko systemd[1]: Starting Automounts filesystems on demand...
Dec 05 07:47:00 sedenko systemd[1]: tmp-autobcyaHg.mount: Succeeded.
Dec 05 07:47:00 sedenko systemd[1]: tmp-autoD8Ji5c.mount: Succeeded.
Dec 05 07:47:00 sedenko systemd[1]: Started Automounts filesystems on demand.
Dec 05 07:47:23 sedenko kernel: EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null)
Dec 05 07:47:35 sedenko systemd[1]: run-user-476.mount: Succeeded.
Dec 05 07:47:35 sedenko systemd[2221]: run-user-476.mount: Succeeded.

sdf1 is an external usb drive.

10

Tried changing the name and the permissions

chmod a+wt /scratch

Still no automatic mount.

11

Using another name for the mount point should not be different.

Changing ownership and/or permissions of the mount point should only effect access for users/groups AFTER mount, but should not influence mounting itself.

12

Tumbleweed is not different. You may post what is going on:

erlangen:~ # journalctl  -b --grep mount
-- Logs begin at Sat 2019-11-23 19:19:51 CET, end at Thu 2019-12-05 12:04:11 CET. --
Dec 04 15:01:09 erlangen kernel: Mount-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
Dec 04 15:01:09 erlangen kernel: Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
Dec 04 15:01:09 erlangen systemd[1]: Condition check resulted in dracut pre-mount hook being skipped.
Dec 04 15:01:10 erlangen systemd[1]: Mounting /sysroot...
Dec 04 15:01:10 erlangen systemd[1]: Mounted /sysroot.
Dec 04 15:01:10 erlangen systemd[1]: Condition check resulted in dracut mount hook being skipped.
Dec 04 15:01:10 erlangen kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Dec 04 15:01:10 erlangen kernel: EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: data=ordered
Dec 04 15:01:11 erlangen kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
Dec 04 15:01:10 erlangen systemd[1]: Mounted /home-HDD.
Dec 04 15:01:43 erlangen plasmashell[2565]: org.kde.plasma: invalid metadata "/usr/lib64/qt5/plugins/libkcm_device_automounter.so"
Dec 04 15:01:44 erlangen systemd[1]: Mounting FUSE Control File System...
Dec 04 15:01:44 erlangen systemd[1]: Mounted FUSE Control File System.
Dec 04 15:01:53 erlangen systemd[2440]: run-user-477.mount: Succeeded.
Dec 04 15:01:53 erlangen systemd[1]: run-user-477.mount: Succeeded.
Dec 04 16:11:03 erlangen plasmashell[8746]: org.kde.plasma: invalid metadata "/usr/lib64/qt5/plugins/libkcm_device_automounter.so"
Dec 04 16:11:13 erlangen systemd[8597]: run-user-477.mount: Succeeded.
Dec 04 16:11:13 erlangen systemd[1]: run-user-477.mount: Succeeded.
Dec 04 16:11:13 erlangen systemd[2440]: run-user-477.mount: Succeeded.
erlangen:~ #
13

First the partition is mounted


sedenko:~ # journalctl  -b --grep mount
...
Dec 09 08:21:36 sedenko kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
...

But then it is unmounted together with the BTRFS subvolumes


Dec 09 08:21:37 sedenko systemd[1]: Unmounting /.snapshots...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /boot/efi...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /boot/grub2/i386-pc...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /boot/grub2/x86_64-efi...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /opt...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /root...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /scratch...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /srv...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /usr/local...
Dec 09 08:21:37 sedenko systemd[1]: Unmounting /tmp...
Dec 09 08:21:37 sedenko systemd[1]: \x2esnapshots.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /.snapshots.
Dec 09 08:21:37 sedenko systemd[1]: boot-efi.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /boot/efi.
Dec 09 08:21:37 sedenko systemd[1]: boot-grub2-i386\x2dpc.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /boot/grub2/i386-pc.
Dec 09 08:21:37 sedenko systemd[1]: boot-grub2-x86_64\x2defi.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /boot/grub2/x86_64-efi.
Dec 09 08:21:37 sedenko systemd[1]: opt.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /opt.
Dec 09 08:21:37 sedenko systemd[1]: root.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /root.
Dec 09 08:21:37 sedenko systemd[1]: srv.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /srv.
Dec 09 08:21:37 sedenko systemd[1]: scratch.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /scratch.
Dec 09 08:21:37 sedenko systemd[1]: usr-local.mount: Succeeded.
Dec 09 08:21:37 sedenko systemd[1]: Unmounted /usr/local.
Dec 09 08:21:37 sedenko systemd[1]: tmp.mount: Succeeded.

After this the partition

/dev/sda4

does not appear again in any log file.

14

Some users report a nasty and uncontrollable feature of systemd: Disk automatically unmounts immediately after mounting | www.bentasker.co.uk Could be related to /etc/fstab using path names (e.g. /dev/sda) instead of UUIDs (e.g. UUID=204f7d0f-979a-41e1-a483-a597d0357e0b). I consistently use UUIDs and never experienced such a problem.

15

This is just a work-around that I’ve been using but I did have this issue for LEAP 15.0 and 42.3

I kept the entry in /etc/fstab then wrote write a script:


#!/bin/bash
sudo mount UUID=your_UUID /yourmount_point

Then gave all permission

chmod 777 your_script

which let me mount without password. I then configured KDE to load this script on boot.

I only had this issue when I disabled a number of timeouts for startup/shutdown sequence to speed things up a bit.

16

I have the same problem on tumbleweed.

17

Well, this IS a Tumbleweed thread.

18

Hello!
My fstab entry is getting ignored too…
I got a folder at /mnt/*data *and i want to automount /dev/sda1 to it.


DESKTOP-KKSJJFU:/home/roland # blkid | grep sda
/dev/sda1: UUID="278ad7a6-e460-426e-9c5f-8653c4f5ee83" TYPE="ext4" PARTUUID="64a9d84b-1892-4ee8-9431-810bd1d08087"

fstab looks like this:


UUID=b2cc5dbc-0021-4992-b342-1a221951dd72  swap                    swap   defaults                      0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /                       btrfs  defaults                      0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /var                    btrfs  subvol=/@/var                 0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /root                   btrfs  subvol=/@/root                0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=e82b41ae-dfa1-4502-aa69-ebc02fcd2a64  /home                   xfs    defaults                      0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=dbb2ab57-6aa3-4def-80f6-976b979ed370  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=548A-13E3                             /boot/efi               vfat   defaults                      0  2
UUID=278ad7a6-e460-426e-9c5f-8653c4f5ee83  /mnt/data               ext4   data=ordered,defaults         0  0

and the suggested “*journalctl -b 0 | grep mount” *tells me that the drives gets unmounted by systemd.

DESKTOP-KKSJJFU:/home/roland # journalctl -b 0 | grep mount
Jan 27 22:52:57 localhost systemd[1]: Condition check resulted in dracut pre-mount hook being skipped.
Jan 27 22:52:58 localhost systemd[1]: Condition check resulted in dracut mount hook being skipped.
Jan 27 21:52:59 localhost systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
Jan 27 21:52:59 localhost systemd[1]: Starting Remount Root and Kernel File Systems...
Jan 27 21:52:59 localhost systemd[1]: sysroot.mount: Succeeded.
Jan 27 21:52:59 localhost systemd[1]: Started Remount Root and Kernel File Systems.
Jan 27 21:52:59 localhost kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered
Jan 27 21:52:59 localhost kernel: xfs filesystem being mounted at /home supports timestamps until 2038 (0x7fffffff)
Jan 27 21:52:59 localhost systemd-fsck[665]: 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Jan 27 21:52:59 localhost systemd[1]: Unmounting /mnt/data...
Jan 27 21:53:00 localhost systemd[1]: mnt-data.mount: Succeeded.
Jan 27 21:53:00 localhost systemd[1]: Unmounted /mnt/data.
Jan 27 21:53:05 DESKTOP-KKSJJFU plasmashell[2014]: org.kde.plasma: invalid metadata "/usr/lib64/qt5/plugins/libkcm_device_automounter.so"

Is this a known issue or needs to be reported?

greetings Kump

19

No, it is not.

I got a folder at /mnt/*data *and i want to automount /dev/sda1 to it.

Which is exactly what happens.

Jan 27 21:52:59 localhost systemd[1]: Unmounting /mnt/data…
Jan 27 21:53:00 localhost systemd[1]: mnt-data.mount: Succeeded.
Jan 27 21:53:00 localhost systemd[1]: Unmounted /mnt/data.

You cannot unmount something that is not mounted.

Is this a known issue or needs to be reported?

The issue that systemd unmounts just mounted filesystems early in boot is known.