Entry in fstab but Authentication is still required to mount partition

mtbvfr · Yesterday 09:41:52

Hi Folks,

I partitioned the drive with GParted using the Live DVD for the 32bit version of Devuan 5 before installation of the Operating System.

When I try to access the partition that is to be used for storage of the User's files, I am prompted with an Authentication dialogue window.

I have added an entry to the fstab file for this partition but I am still being prompted with an Authentication dialogue window.

What's the fix?

Thanks!!

mtbvfr · Yesterday 09:55:28

It would help if I included the fstab entry wouldn't it?

It's like the following one but with a different User Name and UUID.

UUID=65dfc273-13a4-4d93-8dec-7f2f59f43a3b	/media/mtbvfr/LinuxDataExt-4TB	ext4	defaults,nosuid,nodev,relatime,data=ordered	0	0

mtbvfr · Yesterday 10:03:19

Adding the rw option after defaults appears to have it fixed it but is that the correct way to do it?

If I had allowed the installation process to format things, how would have fstab have been configured?

Should I chown the partition to the User account or only its root directory or should I only give Read & Write Access to the Group with the same name as the User Name?

RedGreen925 · Yesterday 13:31:24

Adding the rw option after defaults appears to have it fixed it but is that the correct way to do it?
If I had allowed the installation process to format things, how would have fstab have been configured?

The correct way would have been to allow the system to do it then correct for problems if any were encountered. With the system doing it you would have had nothing but defaults for the options with an ext4 system not the vfat options now set on it you have done. And correct file system checking enabled with the pass number being set to 2. This is the second 0 you have set now so your filesystem will never be checked for errors. That part of the line should be defaults 0 2. The mount point (LinuxDataExt-4TB) should be owned by the user to prevent file/directory creation problems. Oh and check the root line to make certain the last number is the 1 it is supposed to be.

rolfie · Yesterday 17:09:12

When you write a partition table on a device no matter if its new or used already, create a new partition, format a partition, all of these are root tasks. There is no automatic permission for user access past that process.
To allow unprivileged user access to new drives/partitions, you will have to (as root again) change the ownership of the mount point in a single user case or for multiple users to create new directories on the device and assign individual user ownership with e.g. chown.
In addition, all modern desktops like Mate, Cinnamon, Gnome, KDE ... have automounter features that mount for example any USB stick with user rights to the desktop. At least for vfat, exfat drives. It becomes a bit more complicated with ntfs or Linux file systems like ext2/3/4.

You see its complex, depending on.

If you want that device LinuxDataExt-4TB to be permanently connected, I would first of all suggest to use a dedicated subdirectory under /mnt for that drive. Then it makes sense to create a fstab entry like:

Dev-UUID /mnt/xyz ext4 defaults 0 2

The 2 on the end makes sure the file system on the device is checked regularly. Nothing else is required.

In case its an external drive via USB, I do not use any fstab entry, I'll leave opening/mounting when connected to the automounter. They usually create something like /media/$USER/LinuxDataExt-4TB assuming "LinuxDataExt-4TB" is the label that is set on the device.

During the installation it is not directly possible to create/partition/include something like backup drives not really related to the system setup. That's a task for past the first successful boot of the system.

mtbvfr · Today 01:45:51

RedGreen925 wrote:

not the vfat options now set on it

The file system type is set as ext4.

Which are the vfat options that you are referring to?

RedGreen925 · Today 02:15:49

The file system type is set as ext4.
Which are the vfat options that you are referring to?

It would be these the type is separate from them, anything after the defaults are options passed to the file system on mount. Oh and BTW defaults already gives you rw option the extras were screwing it up.

,nosuid,nodev,relatime,data=ordered

The arch wiki shows those used with a vfat file system, there is one ,user used in an example for ext4 all the rest have nothing but defaults..

https://wiki.archlinux.org/title/Fstab

steve_v · Today 04:11:21

nothing but defaults

And if the OP wants those mount options? Those are all perfectly reasonable flags to set on a "data files only" filesystem.

options with an ext4 system not the vfat options now set on it
...
The arch wiki shows those used with a vfat file system

VFAT has nothing to do with anything, and no it doesn't. It simply shows noexec,nosuid,nodev as part of a generic example fstab.
Those flags are reasonable for pretty much any filesystem that doesn't contain executables, suid executables, or device nodes (this is usually suggested as "security hardening", and of rather of dubious benefit). That they happen to be set on a vfat filesystem in that specific example means nothing.

Not only is there is nothing vfat specific in the OP's mount flags, some of them aren't even valid for vfat anyway. OTOH, they are all both valid and perfectly sensible for (non-root) ext4.

the extras were screwing it up

Rubbish. data=ordered and relatime are superfluous as they are defaults these days, and the rest are quite ordinary flags for a non-root filesystem.

There is nothing "complicated" here, 'man fstab', 'man mount', and 'man ext4' cover pretty much anything one would want to know... including the the 'user' mount option, which is most likely what the OP has been after all along.

Why does nobody read the manuals?

Last edited by steve_v (Today 04:57:56)

mtbvfr · Today 09:50:13

Hi Guys @RedGreen925, @rolfie and @steve_v,

Thanks!! for all your input.

My I.T. invovlvement began in December 82 in a Mainframe Operations environment. NCR and then IBM. After 5+ years of fkn shiftwork, I got into the programming side of things starting with COBOL and Wang Procedure Language.

My vision is currently stuffed (screwed, fucked, whatever vernacular tickles your facncy) you could say. So, I'm always looking for quick but sound solutions with easily sourced comprehensive technical documentation where necessary. One of my pet peeves is lousy and incomplete documentation.

My use of Linux began in 2014 after I got my first Laptop (Lenove B590 with no OS) on which I installed Windo$e 8 (what a disaster). Was installed without Secure Boot from the beginning in preparation for dual-booting with Linux. I began with a version of Linux Mint that was only valid for 3 months which caused me some upgrade problems. I learnt about the systemd crap during that year as well as other nefarious crap going on. I switched to a non-systemd Manjaro based distro for a while which became defunct unfortunately.

I dabbled with Debian a bit also before the systemd takeover was done. I even made a persistent version installation of it on a USB Flash Drive.

I eventually got onto MX Linux and started looking at Devuan when it became available. Stuck with MX Linux because there were teething issues when migrating from Devuan1 to Devuan 2 but good to see it has now matured.

I was helping make improvements with luckyBackup mostly with English to Spanish translation at one time. I had dabbled with YAD also to improve the interface and some basic expected functionality but can't remember the exact details now.

I think my fstab configurations are based on what was orignally created by the installation of Linux Mint.

I had already started on the page, suggested by @RedGreen925 in Post #7, before I submitted my Post #6.

I also looked at the following 2 pages.

https://man.archlinux.org/man/mount.8#F … NT_OPTIONS

https://wiki.debian.org/fstab

It would be great if the manuals were more comprehensive. For example, I had to do a string search on character or block special devices on the filesystem to learn what the dev and nodev options are for.

The following pages gave better insight but unsure if needed for my use case.

https://sebastien-copin.com/posts/the_n … unt_option

https://www.suse.com/support/kb/doc/?id=000020660

Does what Sebastien describes present itself for my scenario for a tech illiterate user, who just needs to store their own media and document files on the partition? What would you all suggest?

Similarly, suid and nosuid are not expanded on in the first 3 pages I mentioned. Am I correct in guessing that it was the nosuid that was preventing the default rw option from being enabled?

If such a partition is to be shared between 2 Linux installations, can both installations own the partition or would it be better to give the user Read and Write access to the Root directory of the Data partition within each OS?

Thanks!!, MTB.

steve_v · Today 11:30:24

I'm always looking for quick but sound solutions with easily sourced comprehensive technical documentation where necessary.

There's nothing quicker than 'man' (and 'apropos', to find the right manual), since those manuals are already on your system. '/' for string search in the viewer (it's pretty much just the 'less' pager).
More comprehensive manuals are often available with 'info', though that varies by package.

I still have no idea why everyone goes straight for random blog posts and online copies of manuals... 'man' is faster, available almost everywhere, and doesn't require a web browser.

Does what Sebastien describes present itself for my scenario for a tech illiterate user, who just needs to store their own media and document files on the partition?

It presents as a very niche attack vector, requiring a specific set of conditions and permissions. For most people it's irrelevant.

What would you all suggest?

I'd suggest you do whatever you like. There's no real reason not to set 'nodev' on a non-root "media and documents" filesystem, so you might as well.

Similarly, suid and nosuid are not expanded on in the first 3 pages I mentioned.

It instructs the kernel whether or not to honour the suid and cap_sys_admin bits on executables, what else is there to "expand on"?

Exploiting suid executables also requires specific conditions and root permissions at some point, but again, since disabling suid does no harm on a data filesystem, you might as well.

Am I correct in guessing that it was the nosuid that was preventing the default rw option from being enabled?

I highly doubt it. It was likely the lack of the 'user' flag, since that is exactly what it's for. 'rw' is a default mount option anyway.
It could also be some weirdness of your file manager of course, but since you didn't specify what you're using, in which desktop environment, or what kind of "Authentication dialogue" you saw, who would know.

One additional trap to be aware of: If you use the 'user' flag, only the user who mounted the filesystem will be allowed to unmount it. That means the combination of 'user' and 'auto' will likely result in root mounting the filesystem at boot, and authentication being required for an unprivileged user to unmount it later. See the 'users' and 'group' flags for alternatives.

For reference, entry for the 4TB spinning-rust RAID1 in my desktop is:

LABEL=rust                      /mnt/rust       ext4    noatime,user,noauto        0 2

Which results in:

/dev/md2 on /mnt/rust type ext4 (rw,nosuid,nodev,noexec,noatime,user)

And it mounts and unmounts just fine from a GUI file manager (dolphin), without elevated permissions.
Note:

man mount 8 wrote:

user
...
this option implies the options noexec, nosuid, and nodev

So we don't need explicit noexec, nosuid, or nodev, and:

man fstab wrote:

The kernel default is usually rw, suid, dev, exec, auto, nouser, and async.

So most of the time you don't need to add explicit (filesystem specific) 'defaults' for ext4 either.

If such a partition is to be shared between 2 Linux installations, can both installations own the partition or would it be better to give the user Read and Write access to the Root directory of the Data partition within each OS?

An OS installation doesn't "own" a filesystem in any way (unless it's ZFS, but I digress), *nix is a network OS at heart and permissions are all about users and groups.

Who can do what and where simply comes down to whether the users effective UID/GID (i.e. numeric user and/or group identifier) matches the file/directory owner UID/GID.
If you set up your user account to have the same UID on both installs, that user will have the same permissions for the same files regardless of which OS you boot... And I suggest you do set up identical usernames with the same UID, because anything else is a kind of a confusing PITA (e.g. "bob" (UID 1000) on machine 1 can write to the disk, but "bob" (UID 1001) on machine 2 can't, so Bob is annoyed).

Aside:

RedGreen925 wrote:

The mount point (LinuxDataExt-4TB) should be owned by the user to prevent file/directory creation problems.

No, no it should not. Mountpoint directory permissions should be root:root, they will be replaced with those of the root of the mounted filesystem (i.e. mount the filesystem, then chown, not the other way around).
Granting write on a mountpoint directory to an unprivileged user is just a super effective way to let that user fill up root when the filesystem is not mounted.

Last edited by steve_v (Today 12:42:43)

greenjeans · Today 15:57:13

Wow, I needed more coffee before I read this thread. Lotsa stuff...

FWIW IMHO best protocol:

1. Gparted: setup partitions
2. Devuan: Install normally and let system set normal permissions.

"But I want system to see other partitions including USB devices and let me open/read/use them with just a click from the user"

3. Then open /usr/share/polkit-1/actions/org.freedesktop.Udisks2.policy and edit accordingly. Settings will persist.

Last edited by greenjeans (Today 15:57:53)

chris2be8 · Today 17:36:42

One suggestion, running mount without parms will show what options all the currently mounted filesystems have ended up with. So checking that after each try will tell you if you did what you wanted to.

Another suggestion, mountpoints should be owned by root with permissions 555. If you run ls -al in the root of a mounted filesystem it wil read the .. entry from the mountpoint. So you need to be able to read the mountpoint for that. But don't let non-root users write into it.

The officially official Devuan Forum!

#1 Yesterday 09:41:52

Entry in fstab but Authentication is still required to mount partition

#2 Yesterday 09:55:28

Re: Entry in fstab but Authentication is still required to mount partition

#3 Yesterday 10:03:19

Re: Entry in fstab but Authentication is still required to mount partition

#4 Yesterday 13:31:24

Re: Entry in fstab but Authentication is still required to mount partition

#5 Yesterday 17:09:12

Re: Entry in fstab but Authentication is still required to mount partition

#6 Today 01:45:51

Re: Entry in fstab but Authentication is still required to mount partition

#7 Today 02:15:49

Re: Entry in fstab but Authentication is still required to mount partition

#8 Today 04:11:21

Re: Entry in fstab but Authentication is still required to mount partition

#9 Today 09:50:13

Re: Entry in fstab but Authentication is still required to mount partition

#10 Today 11:30:24

Re: Entry in fstab but Authentication is still required to mount partition

#11 Today 15:57:13

Re: Entry in fstab but Authentication is still required to mount partition

#12 Today 17:36:42

Re: Entry in fstab but Authentication is still required to mount partition

Board footer