How can I provide authorization to mount internal drives at boot automatically?

Every time I boot, I am asked to provide superuser authentication to mount the 2nd internal NVMe drive on my motherboard.

image

How can I automate this? Coming from Windows originally, this has always seemed to me to be a rather absurd of a thing to have to do after every OS initialization.


I’ve also always been slightly bothered by the unnecessary padding after the description. >:(

Can you post the contents of the /etc/fstab file?

1 Like

@WilsonEPhillips,

Get-Content '/etc/fstab'
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /                       btrfs  defaults                      0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /var                    btrfs  subvol=/@/var                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /root                   btrfs  subvol=/@/root                0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /home                   btrfs  subvol=/@/home                0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=7ffbb2f4-3e39-410c-9fea-48964cf2ccd1  swap                    swap   defaults                      0  0
UUID=9574-544B                             /boot/efi               vfat   utf8                          0  2

Thanks lots.

Since your mounts are all by UUID, and your original question does not state where it mounts when you put in the password, can you tell us where it actually mounts? I am guessing that it is not listed in /etc/fstab at all.

By the way, you can use the comand
sudo blkid
and see what the UUID of the nvme1n1p1 is. Do this after you have mounted the drive by putting in the password for root.

1 Like

This is what my /etc/fstab looks like. The drives at the bottom were added manually. Of course you must know what the mount point should be, or what you want it to be. You must also know the formatting of the drive to know what options you want to apply to it. Yes, there is some extra commenting in there.

# Created by Wilson Phillips May 31, 2023
#
# / root must ALWAYS be mounted first! The rest can be in any order.
#
#	<Disk UUID Name>						<Mount Point>		   <Type>	<Mounting Options>																				<Path Information>
# NVME0 500 GB (Very Fast)
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /                       btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async									0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /var                    btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/var         	        0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /usr/local              btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/usr/local           	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /srv                    btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/srv                 	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /root                   btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/root                	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /opt                    btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/opt                 	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /boot/grub2/x86_64-efi  btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/boot/grub2/x86_64-efi	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /boot/grub2/i386-pc     btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/boot/grub2/i386-pc  	0  0	#  /dev/nvme0n1p2
UUID=6dd2d662-8bcb-4ab5-a58c-4df075074264  /.snapshots             btrfs  rw,noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=/@/.snapshots          	0  0	#  /dev/nvme0n1p2
UUID=2618-10E1                             /boot/efi               vfat   utf8                          															0  2	#  /dev/nvme0n1p1
#
# NVME1 1,000 GB (Very Fast)
UUID=f27036e4-4e3c-4186-8070-b58acb26b549  /home                   ext4   data=ordered                  															0  2	#  /dev/nvme1n1p1
#
# HHD 4,000 GB (Slow)
UUID=a89fa57b-f843-44d6-a135-e095946f998e  /4TB-HDD                ext4   user,data=ordered                															0  2	#  /dev/sda1
#
# SSD 500 GB (Fast)
UUID=235e9ce5-2189-4e85-875e-9b5c6d639357  /VMs                    ext4   user,data=ordered     	        														0  2	#  /dev/sdb1
#
# SSD 1,000 GB (Fast)
UUID=e828232f-58c6-4cb4-a2ca-62cbb12a6a41  /HomeBack               ext4   user,data=ordered             															0  2	#  /dev/sdc1

This is what the sudo blkid looks like for those same drives.

┌──[wilson@heisenberg] Sun Jul 30, 10:44:24 [~] 
└──[ <$> sudo blkid
[sudo] password for root: 
/dev/nvme0n1p1: UUID="2618-10E1" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="584a23ae-61a3-439e-abf8-465d75bc700f"
/dev/nvme0n1p2: UUID="6dd2d662-8bcb-4ab5-a58c-4df075074264" UUID_SUB="a79f50f8-bcbb-4955-9f79-4b1eed0c021b" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="770ae16e-24cd-4681-ad22-423fbb93387d"
/dev/sdb1: LABEL="VMs" UUID="235e9ce5-2189-4e85-875e-9b5c6d639357" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="82b3357a-01"
/dev/sdc1: LABEL="HomeBack" UUID="e828232f-58c6-4cb4-a2ca-62cbb12a6a41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6bb2935c-c273-2040-87d8-dc6394153cdf"
/dev/nvme1n1p1: UUID="f27036e4-4e3c-4186-8070-b58acb26b549" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a9e3358b-506b-4686-b9ae-9b8aac67087c"
/dev/sda1: LABEL="4TB-HDD" UUID="a89fa57b-f843-44d6-a135-e095946f998e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="fda183db-379c-0646-807e-0d296a18ea6b"
/dev/zram0: UUID="333ceae7-ce3a-4e11-95ec-ae7f4ea9bf32" TYPE="swap"

As you can see, the drives show UUID and PARTUUID, so they could be mounted either way. They can also be mounted as /dev/nvme1n1p1 for example. Just replace the UUID with the path. fstab will work either method.

1 Like

@WilsonEPhillips, it mounts to /run/media/rokejulianlockhart/RWPR04/ because I set that as the label of the drive’s sole partition in partitionmanager. Previously, it mounted to /run/media/rokejulianlockhart/$UUID/, but the behaviour was identical.

sudo blkid outputs /dev/nvme1n1p1: LABEL="RWPR04" UUID="4b2478fd-5b2b-4927-91fb-19d9c9ef3087" UUID_SUB="8b813378-5718-4b88-9655-5b5100c17824" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="e0261017-63d8-b148-a5e6-e38fad478949".

The full output is

sudo blkid
/dev/nvme0n1p2: LABEL="RWPQZT" UUID="01306e9f-2ee7-4144-8878-16b04ff549dc" UUID_SUB="ff434346-b4e9-49d7-a3af-ca3052dbbaf2" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="1fd59ab2-4c08-47f4-86e7-a5fea7f3e8d0"
/dev/nvme0n1p1: UUID="9574-544B" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1083f27e-827f-43dd-933e-80cc776111a6"
/dev/nvme0n1p3: UUID="7ffbb2f4-3e39-410c-9fea-48964cf2ccd1" TYPE="swap" PARTUUID="6036280e-3600-4498-8b20-d19e23b8f0b1"
/dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop29: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop19: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop47: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop37: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop27: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop17: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop45: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop8: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop35: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop25: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop15: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop43: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop6: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop33: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop23: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop13: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop41: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop4: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop31: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop21: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop11: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop2: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop48: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop38: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop28: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop18: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop46: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop9: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop36: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop26: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop16: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop44: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop7: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop34: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme1n1p1: LABEL="RWPR04" UUID="4b2478fd-5b2b-4927-91fb-19d9c9ef3087" UUID_SUB="8b813378-5718-4b88-9655-5b5100c17824" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="e0261017-63d8-b148-a5e6-e38fad478949"
/dev/loop24: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop14: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop42: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop5: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop32: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop22: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop12: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop40: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop3: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop30: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop20: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop49: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop10: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop39: BLOCK_SIZE="131072" TYPE="squashfs"

Regarding the /etc/fstab file, considering

I think I’d rather not touch it if possible, although I’ll definitely try if I can’t fix this via a GUI.

Consequently, do you reckon that

could work in the meantime? I’d never noticed it had local autofill functionality until now.

If I didn’t misstype anything, you should be able to add this line to the bottom of your /etc/fstab and it will mount it automatically. You can edit the path of /RWPR04 to put it wherever you want it, but it will be fine in this spot. If you have things that point to the other location, you will need to mount it there.

UUID=4b2478fd-5b2b-4927-91fb-19d9c9ef3087 /RWPR04 btrfs defaults 0 0

For the path you already have,

UUID=4b2478fd-5b2b-4927-91fb-19d9c9ef3087 /run/media/rokejulianlockhart/RWPR04 btrfs defaults 0 0

By the way, this is Linux. Not everything can be done from the GUI or should be.
If you don’t like nano or vi or vim, you might try micro. On some distros, it is just micro, but on openSUSE, it is micro-editor, so you will have to look to see.

1 Like

@WilsonEPhillips,

Using

and GitHub - PowerShell/PowerShell: PowerShell for every system!, I ran

Add-Content -LiteralPath '/etc/fstab' -Value 'UUID=4b2478fd-5b2b-4927-91fb-19d9c9ef3087 /run/media/rokejulianlockhart/RWPR04 btrfs defaults 0 0'
PS /home/rokejulianlockhart> sudo -i  
RQN6C6:~ # pwsh
PowerShell 7.3.6
PS /root> Add-Content -LiteralPath '/etc/fstab' -Value 'UUID=4b2478fd-5b2b-4927-91fb-19d9c9ef3087 /run/media/rokejulianlockhart/RWPR04 btrfs defaults 0 0'
PS /root> Get-Content -LiteralPath '/etc/fstab'
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /                       btrfs  defaults                      0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /var                    btrfs  subvol=/@/var                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /root                   btrfs  subvol=/@/root                0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /home                   btrfs  subvol=/@/home                0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=01306e9f-2ee7-4144-8878-16b04ff549dc  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=7ffbb2f4-3e39-410c-9fea-48964cf2ccd1  swap                    swap   defaults                      0  0
UUID=9574-544B                             /boot/efi               vfat   utf8                          0  2
UUID=4b2478fd-5b2b-4927-91fb-19d9c9ef3087 /run/media/rokejulianlockhart/RWPR04 btrfs defaults 0 0
PS /root> Restart-Computer

and it worked! Thanks, loads!


I don’t need CLI text editors to edit superuser-protected files because https://code.visualstudio.com/ works just fine with them too. Thanks, though.


I’d love to put this in my setup script. Any idea how to determine which drives to add to fstab programmatically? I suppose I could just regex any nvme*. entries in blkid.

You can put any drive into /etc/fstab and mount them at any point you want. You can mount them by the UUID from blkid or you can mount them by the path /dev/sda1 or /dev/nvme1n1p2. You can mount drives that are shared from another PC. There is a lot you can do to automatically mount drives.

1 Like

JFYI, this is an openSUSE issue. The distro gets to decide whether to show or suppress the authorization dialog for actions that require elevated permissions (as this does), and on openSUSE, they show it.

See 1116084 – Auto-mounting encrypted external disk requires root password. You’ll find the same thing in Discover when you eventually install a Flatpak app. For that, see 1123722 – flatpak: bad user experience when polkit actions are more conservative than the default.

2 Likes

Thanks lots for this. Indeed, I don’t recall this being problematic on Fedora, so knowing that it’s being tracked and fixed is great to hear.