[SOLVED]New partitions do not mount automatically without su password?

mikael78 · 2026-01-12 21:17:47

Hi,
I used gparted to make 2 partitions on empty space on 1tb disk as primary partitions after making initial only
one partition smaller using live disk.

I have 2 accounts on the instal, root and user.

Problem is that everytime the laptop is started and logged in as user it won't mount the new partitions
and asks root password inside user account.

I did try to set read/write permissions to partitions using file manager and logged in as root.

Also used chown on user account terminal logged in as root to change /media/user/levy1 ownership to user and giving write/read
permissions thru file manager to user.

Nothing seems to help..

when logging in first time as root and checking sda3/4 partition file paths it shows
/media/root/levy1
and as user login and mount
/media/user/levy1

what am I doing wrong?

ls -ld /media/user/levy1 returns
drwxrwxr 3 user user

Last edited by mikael78 (2026-01-13 20:21:27)

mikael78 · 2026-01-12 21:23:00

When I restart the laptop it starts the new partitions as unmounted no matter wich side I log in, root or user.
tried chatgtp, but did not get clear answers other than chown..

Xfce and sysVinit in use.. ext4 file system.

Last edited by mikael78 (2026-01-12 21:55:38)

mikael78 · 2026-01-12 22:00:00

chatgtp says I need to add the new partitions using nano to fstab as new entries??

mikael78 · 2026-01-12 22:11:40

Would setting a flag to these two partitions thru gparted help? Would gparted then ad the lines to fstab?
Really don't wan't to make this unbootable by making a mistake to fstab..🤨

greenjeans · 2026-01-12 22:30:20

/usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy

Edit as needed.

<!-- Mounting filesystems -->
<action id="org.freedesktop.udisks2.filesystem-mount">
  <description>Mount a filesystem</description>    
  <message>Authentication is required to mount the filesystem</message>    
  <defaults>
    <allow_any>auth_admin</allow_any>
    <allow_inactive>auth_admin</allow_inactive>
    <allow_active>yes</allow_active>   <<<--------change "auth_admin_keep" to a "yes" as shown here.
  </defaults>
</action

Last edited by greenjeans (2026-01-12 22:42:02)

mikael78 · 2026-01-12 23:19:15

Thanks for the info. This is what chatgtp said, also said that doing it like that would not be permanent solution
for example over updates etc. or preferred way thinking about security.

"Just to make it easier for tomorrow, here’s a mental checklist so you don’t forget:

Check the new partition with lsblk -f to get its UUID and filesystem.

Decide on a permanent mount point (e.g., /media/data or /mnt/data).

Create the directory with sudo mkdir -p /media/data.

Set ownership to your user (sudo chown -R user:user /media/data).

Add an /etc/fstab entry with the UUID, filesystem type, and defaults options.

Test it immediately with sudo mount -a before rebooting."

And making backup also before editing fstab.

Which is better way?

I guess since the mount path is changing depending first login user the paths are not permanent.
Thats why mkdir needs to be used.

Last edited by mikael78 (2026-01-12 23:32:40)

steve_v · 2026-01-13 04:52:18

Would setting a flag to these two partitions thru gparted help? Would gparted then ad the lines to fstab?

Possibly. I vaguely recall gparted having an option to set a mount point (or maybe that was KDEs 'partitionmanager'), but that won't be any kind of "flag" set on the partition - it's offering to modify /etc/fstab for you.
I've never used it, and frankly I wouldn't trust it to not make a mess in my nice readable column-aligned file.

Really don't wan't to make this unbootable by making a mistake to fstab

Don't mess with the line for the root filesystem, and it'll be fine.
Even if you did somehow manage screw that up, such things can be fixed by chrooting in from a livecd or the install media (as can 99% of "unbootable" situations in general).

what chatgtp said

Why are you asking a large ~~language~~ regurgitaion model for information that is readily available with a 15 second web search, or locally with:

man fstab

and

man mount

?
Fstab syntax is not complicated, and examples are all over the 'net.

For most purposes:
* Create a directory to use as the mount point and check/set permissions.
* Edit /etc/fstab to add a matching line, where the (space separated) fields are:
[device] [mount point] [filesystem type] [options] [dump priority] [check priority]
* Test that it works as intended with 'mount [mount point]'.

The first field can be a traditional device node (e.g /dev/sd[x][y]), any symlink under /dev/disk/by-[whatever] (e.g. /dev/disk/by-id/[drive model and serial number]), a 'UUID' tag (e.g. UUID=[filesystem UUID]), or a 'LABEL' tag (e.g. LABEL=[filesystem label].
Note that /dev/sd[x][y] names are assigned in the order the kernel detects devices, so they may shift around. That's why many examples prefer UUID, but there are several other options.
If you want to use UUID, you can print it with 'blkid -o value -s UUID [device node]'

Mount point can be any directory you like. Preferably an empty one, as mounting will "overlay" existing contents making it inaccessible (well, mostly, but that's into the weeds).

Filesystem type is self-explanatory, or 'auto' if you're lazy (or like to swap drives around).

Available options are explained in the mount manual, fstab takes the same format as the '-o' command-line option for the mount command.

The last two fields determine the order filesystems are dumped (don't worry about it) and checked. For non-root filesystems the usual is '0 2'.

** In case it's not obvious, where I say [foo], you're supposed to fill in your value and drop the enclosing [].

A couple of random examples from my systems, I prefer labels to UUIDs:

LABEL=spool    /mnt/spool    ext4    noatime    0    2

Unless it's a hotswap bay and I want to identify it by a specific SATA port, so any disk I put in it mounts at the same place:

/dev/disk/by-path/pci-0000:00:17.0-ata-1-part1    /mnt/bay1    auto    user,noatime,noauto,exec    0    2

Which is better way?

If you mean polkit rules or fstab... They're answering different questions, because there are (at least) two mechanisms for "automatically" mounting filesystems.
/etc/fstab is system level, and is processed before any user logs in. If the filesystem is permanent and you want it always mounted regardless of what user or environment you are using, this is the most reliable method.

Polkit rules are used to allow an unprivileged user to mount things that are not in /etc/fstab, or things that are in /etc/fstab but don't have 'user' in the options field (since either of those scenarios would normally require root permissions).
Polkit is generally only used by graphical desktop/file managers, (i.e. not by the 'mount' command at the CLI), and will only help with "automatic" mounting if your GUI or file manager of choice has a facility of its own to "remember" mounted filesystems and re-mount them at login.

Last edited by steve_v (2026-01-13 05:30:53)

greenjeans · 2026-01-13 16:53:03

Okay, maybe i'm misunderstanding the OP and what he wants to accomplish. FWIW, the method I described above works like this:

I boot my machine, I open my file-manager and there in the treeview to the left it displays my other partitions, they are there but not mounted, I left-click one time on one and it mounts it and opens it for me. It's natural and intuitive and fast.

If that's the desired behavior then what I suggested should work for you.

steve_v · 2026-01-13 17:56:17

maybe i'm misunderstanding the OP and what he wants to accomplish.

Nah, the question (is it one question or two? Internal or external drive? Which "file manager"?) is just vague, as usual.
The "automatically" in "automatically and without superuser password" kinda implies "without user action", hence myself (and chumpGPT) heading toward /etc/fstab.

delgado · 2026-01-13 18:18:08

steve_v wrote:

/dev/disk/by-path/pci-0000:00:17.0-ata-1-part1    /mnt/bay1    auto    user,noatime,noauto,exec    0    2

The mount options in the example ("user,noauto") are working with pcmanfm and in a terminal. So probably anywhere else too?!.

Btw. Interesting method to mount a partition using pci-ids. Didn't know tthat. Apreciated.

steve_v · 2026-01-13 18:29:02

probably anywhere else too?

Most things that mount filesystems (udisks, gvfs etc.) look in fstab first before doing the "polkit auth -> mount /media/foo" thing, so yeah, it should. 'user' is particularly handy, but there are some details in the manual you might want to be aware of.

Interesting method to mount a partition using pci-ids

It's just exploiting the fact that mount dereferences symlinks when resolving the device node.
The convenient links under /dev/disk/ are created by udev, so they won't work for the bootloader or on a system that doesn't run udev or doesn't start it before mounting non-root filesystems. I don't know any commonly-used examples of the latter, but it's something to bear in mind.

Last edited by steve_v (2026-01-13 18:44:06)

mikael78 · 2026-01-13 20:05:44

Thanks for all your help. Seems to be many ways of doing this. I used kde partition manager for fstab edit since really don't
like nano. Gparted did not have mount options.

I created /media/disk1 directory and used chown to change owner to user. Then used kde partition manager to choose
the directory. Used uuid. Numerical options were 0 and 0 for internal storage hd partition and I added settings defaults,noatime,nofail to the options list. Checked the box let users acces the drive.

Seems to boot and work ok now.

noatime recommendation came also from chatgtp to save a little the ssd drive.

Any recommendations welcome. I think if I change the values it is best to edit the fstab from terminal.

Last edited by mikael78 (2026-01-13 20:59:50)

mikael78 · 2026-01-13 20:19:27

And it was internal main ssd with two new primary partitions.
Did this since there is Excalibur 6 update available and wanted to transfer some
files to other than one big main partition in case something goes south on update process.

Last edited by mikael78 (2026-01-13 20:39:33)

steve_v · 2026-01-13 20:41:47

Numerical options were 0 and 0

FYI, setting the pass field to '0' will cause startup filesystem check/repair (if needed) to be skipped, this may or may not be what you want.

mikael78 · 2026-01-13 21:03:06

Yes, those are partitions just for storage use.. Is there any short comings for not using option number 2 for normal data storage?
I assume the system with option 0 will inform if having faults when transferring files and then can do disk check/repair?

Last edited by mikael78 (2026-01-13 21:03:53)

steve_v · Yesterday 04:07:19

Not really, though conversely I don't see any reason not to set it to >=2.
The most common reason for a dirty filesystem is a power failure, so IMO the most logical time to fix it is when the system starts up again.
If check is disabled, you might find yourself needing to run fsck manually before you can mount the filesystem, I prefer the system to handle that automatically, at the earliest opportunity.

Setting check to '0' in fstab is roughly analogous to always selecting skip for non-system filesystems in that that startup chkdisk screen Windows will sometimes throw at you if it crashes hard enough or you pull the plug while there's disk activity. No big deal, but unless you're in a mighty hurry there's no reason not to just let it do its thing. Ext4 is a journaled filesystem, so a fsck is usually measured in seconds.

really don't like nano

Feel free to install your preference and change the default CLI/TUI editor with

update-alternatives --config editor

You'll want to be comfortable with some CLI editor, doing things as root through the GUI is both awkward and generally discouraged.
Personally I like mcedit, it (and mc itself of course) should be very familiar to anyone who has used classic Norton Commander or MSDOS edit.

Last edited by steve_v (Yesterday 04:19:18)

The officially official Devuan Forum!

#1 2026-01-12 21:17:47

[SOLVED]New partitions do not mount automatically without su password?

#2 2026-01-12 21:23:00

Re: [SOLVED]New partitions do not mount automatically without su password?

#3 2026-01-12 22:00:00

Re: [SOLVED]New partitions do not mount automatically without su password?

#4 2026-01-12 22:11:40

Re: [SOLVED]New partitions do not mount automatically without su password?

#5 2026-01-12 22:30:20

Re: [SOLVED]New partitions do not mount automatically without su password?

#6 2026-01-12 23:19:15

Re: [SOLVED]New partitions do not mount automatically without su password?

#7 2026-01-13 04:52:18

Re: [SOLVED]New partitions do not mount automatically without su password?

#8 2026-01-13 16:53:03

Re: [SOLVED]New partitions do not mount automatically without su password?

#9 2026-01-13 17:56:17

Re: [SOLVED]New partitions do not mount automatically without su password?

#10 2026-01-13 18:18:08

Re: [SOLVED]New partitions do not mount automatically without su password?

#11 2026-01-13 18:29:02

Re: [SOLVED]New partitions do not mount automatically without su password?

#12 2026-01-13 20:05:44

Re: [SOLVED]New partitions do not mount automatically without su password?

#13 2026-01-13 20:19:27

Re: [SOLVED]New partitions do not mount automatically without su password?

#14 2026-01-13 20:41:47

Re: [SOLVED]New partitions do not mount automatically without su password?

#15 2026-01-13 21:03:06

Re: [SOLVED]New partitions do not mount automatically without su password?

#16 Yesterday 04:07:19

Re: [SOLVED]New partitions do not mount automatically without su password?

Board footer