Boot password is required for additional partitions after each boot

I have a separate data partition on the same SSD as my root partition.
After booting, the data partition is not automatically mounted. You have to click on the partition in dolphin and enter your root/user password (which is the same in my case) to authorise it.

So I added this to the fstab (with the correct UUID of the data partition, of course)

UUID="XXXX-...." /run/media/user/data btrfs defaults,noatime 0 2

After modifying the fstab and rebooting, the Manjaro OS boot screen is displayed, but the OS does not actually boot all the way through.
There may be a simple solution to have the root password added automatically on boot, perhaps similar to what is done with the root partition.
I have searched some of the topics in this forum but have not found a clear answer to my problem.

udisksctl mount -b /dev/disk/by-uuid/UUID

Put this to the autostart and it will mount it at login. That is exactly what Dolphin does when you click to mount.

1./run is a tmpfs and fstab needs an existing mountpoint, otherwise it will fail. Add X-mount.mkdir and it should create it when mounting.
2. Don’t use ""

do not attach it to:

create a separate (unique) mount point - and use that

Thank you.

Does this command mean that it will automatically be put to autostart and it mounts at login than, or do I need to do something else?
Can I use this command exactly as it is, or do I need to replace “UUID” in this command with the UUID of the data partition?

Would either of these versions be correct?

UUID=XXXX-.... /run/media/user/data btrfs defaults,noatime,X-mount.mkdir 0 2


UUID=XXXX-.... /dev/nvme01np3 defaults,noatime,X-mount.mkdir 0 2

What exactly does “unique” mean and why is it wrong?
I created this partition using the KDE partition manager and simply entered the partition name “data”. The partition manager automatically created this mountpoint


Why should it not be unique if it generated?

You need to add it to autostart, or since KDE use the builtin settings.At “Removable Devices” you can tick to mount it on login?

Of course set the correct UUID. Hope you didn’t set exactly UUID=XXXX-.... in fstab. :see_no_evil:

UUID=<this is a placeholder> /some/place/on/fs btrfs defaults,noatime,X-mount.mkdir 0 0

What I meant:
a mountpoint is simply a directory

To be a unique mount point,
to have one,
is as simple as to create a dedicated directory
(which is only present for this one specific purpose)

sudo mkdir /Data
sudo mkdir /MyExtraStuff

Those directories are not otherwise used,
they are unique (depending on the name …)
and they are permanent

… unlike /run/... , for example,
which only exists once the system is halfway booted up …


Why should it not be unique if it generated?

/run/... does only exist because it is being created anew each time the system boots up
It is a dynamically created directory - not a persistent one.

1 Like

With KDE you can add removable devices by mount on login. Yes, I am aware of this feature, but it did not work with /run/media/user/data, but by setting a new mount point like /disks/data it works now.

I would still like to understand how to use the command:

udisksctl mount -b /dev/disk/by-uuid/UUID

I have attached a screenshot of the startup screen. Do I need to add a login script (“Anmeldungs-Skript hinzufügen”)? Do I need to create a file or what kind of text file do I need to add to make the command work? And is it exactly this command or do I have to replace the UUID with the real UUID of the disk partition?

I have attached a screenshot of autostart mask. Do I have to add a login script '? Do I have to create a file or what kind of text file has to be added for making the command work? And is it exactly this command or has the UUID replaced with the real UUID of disk-partition?

When it is finally clear what the solution is, I will write a summary for other searchers. Maybe as a tutorial with reference to your two answers.
For several years I have been struggling with this simple problem of booting properly, because I never got a really clear answer. I could find the solution by combining your answer and Nachlese’s - at least for the non encrypted, no hibernation version.



The combination of letters, here: UUID is a placeholder. So yes, the UUID must exist. Something like: 12345678-1234-1234-1234-123456789abcd

/dev/disk/by-uuid/UUID is a real absolut path in your system. Usually a symbolic link to the real block device, which is called /dev/sdd1 for example.

Check this:

ls -la /dev/disk/by-*/

You can also use /dev/disk/by-label/labelofpartition

1 Like

MeanwhiIe I have tried out some installations for the data partition not using




by creating an on own mouting point with KDE partition manager. It works fine.

But if you want to mount this way an encrypted partition it does not work at all. Even the entry in /etc/fstab is correctly created by KDE partition manager.
It is probably because it asks at boot for the password but it is not provided. Thus it stops booting.

I believe a password file has to be connected in /etc/fstab

UUID=<this is a placeholder> /disks/data btrfs defaults,credentials=/home/user/.datacredentials   0 0

In the self created file /home/user/.datacredentials probably simple this content has to added


How do you think?

Even this works. I am also not happy because the password is just not protected written in a file on the PC in home directory.

I have absolutely zero experience with and only very little understanding of how BTRFS works.
I’ll simply not use it until that changes - it is too different from what I know.

As far as encrypted partitions are involved:
that is where /etc/crypttab comes in

No need to store a password anywhere.