Fstab not working as expected

I just replaced BlendOS (Arch based) on my pc with Slowroll and I copied two of my old fstab lines into the new one. Accessing either of those mounts now requires me to enter my root password on every boot when that didnt’t use to be the case on BlendOS. I’ve already tried changing the permissions to defaults,user and defaults and changing the last value to 0.

UUID=x	/run/media/x/Home	btrfs	rw		0 2
UUID=x				/run/media/x/Share	ntfs	rw		0 2

I am not quite sure I understand what you are doing and seeing, but my eye fell on /run/media/x/Home. Why do you think that that exists?

(And why are you thinking that showing the UUID is a security risk?)

I do not understand that either. During boot things are running “as root”, thus why should the system ask that pasdsword (and how does it do that, on the boot splash?)

1 Like

@J-Kappes do the UUID’s match the output from blkid? Also check the group id/user id’s for the btrfs device.

I think you should use ntfs-3g as filesystem for the ntfs partition. Install the package if necessary. I use Defaults and not rw though.

I created both those mount points.
I meant “once per boot”, not “during boot”.

I didn’t check with blkid yet, but I did with Gnome Disks. And upon entering my password they mount just fine.

Then please explain when exactly. This is very vague. I have no idea when you are asked for the root password (and in what form). Interpreting what you told until now:

Not during boot.
Because asking for the rootpassword, most probably from a session of a “normal” user. Is that a CLI or a GUI session? Is that direct after login, or is that user doing something?

It’s a Gnome pop-up password prompt whenever I first want to access the mount e.g. when clicking the corresponding bookmark I made in the file manager.

That then is a user’s desktop initiated mount.

That is very strange, as you have them in /etc/fstab, they should already have been mounted at boot.

Did you check your log (or looked at what happens at boot by hitting the Esc key) for what happens with those mounts?

And I ask again

Because /run and what is inside is a place for the system. And yes, the system uses that place for mounting on request of a user through the desktop. and organization within /run is done y the system. But that is not a place where you as system manager can “assume” that things are as you wishfully may think so.

The default location for a user initiated mount is “/run/media/USER/FS-LABEL”, if the filesytem has a label, otherwise it will be a disk-by-uuid permutation. Until needed, “/run/media/USER/” does not exist. I will guess that is why is is not mounting at boot.

Easy enough to test!

Reboot your box. DON’T login to gnome. Go to a console screen … “ctrl+alt+F1”. Login terminal as root. If you type “ls /run/media”, it will probably be empty.

I imagine you could fix it my simply typing “mkdir /run/media/USER”, but I don’t KNOW that the directory will stay after reboot. Nor do I know if that might cause other problems.

As said above, it is NOT a good idea to “do things” inside /run. The OP should redesign his policy and decide where, in a logical place, the mounts should be. And that depends on what the file system stores. When that is data for general use, it will be in a general place (could be inside /mnt, or in a place specialy created like /data or /music, or …). If it is space for a specific user one could take a logical place inside that user’s home directory (like /home/<user-name>/music or the like). There is an often used alternative in the latter case: mount it in e.g. /music and then make a symbolic link to a place in that user’s home directory (ln -s /music /home/<user-name>/music).

In all cases special care should be taken to set the permissions of the mount point correct, see that the ownership and permissions of the files inside the mounted file system are correct for the intended usage. And in the case of a non-Linux file system use the correct options on in /etc/fstab to create the correct fake ownership and permissions.

So, UUID of both filesystems are literal x and so are identical? And you use the literal x in the path to the mountpoint? It is of course up to you to obfuscate to your heart’s content, but unless you show something that can be used to reproduce your issue you get yet another endless thread about nothing.

That is what I do, but for “Videos” rather than Music.

ox@orca$ ls -l Videos
lrwxrwxrwx 1 ox ox 17 Dec 21  2023 Videos -> /xtra/av0/videos/
ox@orca$ ls -ld /xtra/av0/videos/
drwx------ 37 ox ox 4096 Jul 25 16:57 /xtra/av0/videos/

And then for the sake of completeness, you should show

mount | grep videos
grep videos /etc/fstab

:wink:

I could, but I fear that would confuse rather than help as the filesystem mounted at /xtra/av0 is actually luks encrypted.

But the OP could certainly use something like:

UUID=3b6c88dd-5973-4246-817a-145957605553  /xtra/av0  ext4  data=ordered  0  2

in /etc/fstab.

Good thinking, I agree.

Out of curiosity I added this line

UUID=ab5e01e9-7174-4c22-9d53-da2be86e6331 /run/media/bor/Home btrfs rw 0 2

and it is mounted on boot and I do not get any password prompt anywhere.

systemd by default creates (full path to) the mount point if it does not exist.

You apparently believe that this explains anything. It does not. We have no idea what “file manager” you are using, where this bootmark is located, what it corresponds to and where this bookmark points.

Your line in /etc/fstab should cause this filesystem to be mounted and become accessible like any other mounted filesystem. What you are doing that results in password prompt is still unknown.

I mean Nautilus, Gnome’s default file manager. The bookmark “is located” in nautilus’s sidebar. Clicking it is the same as trying to open the corresponding directory, i.e. /run/media/myname/Home or Share respectively in Nautilus.

Hm, looks like a service to the system manager with a senior moment. Nevertheless poking around in /run, where others may have the same idea is still not a good idea IMO.

And as several of us now have pointed to: why is the fstab entry not working (and falls the OP back to his user trying to mount through the desktop as if this was a device (s)he connected during her/his desktop session).