umask=0077 is the default after installing Arch using systemd-boot.
# <file system> <dir> <type> <options> <dump> <pass>
UUID=3DE2-72E6 /boot vfat umask=0077 0 2
What I posted was from a Vanilla Arch install as well.
The entry was produced by genfstab before installing Grub even 
Maybe depending on when systems have been installed, something has changed?
Or could it be depending where ESP is mounted? Mine is mounted at /boot/efi. I see yours is mounted at /boot.
That means, it allows other users in the group to read and execute files in the esp partition without requiring root permission.
https://wiki.archlinux.org/title/Genfstab
UUID=E5C7-6DD7 /efi vfat rw,relatime,fmask=0077,dmask=0077, …
1 Like
Interesting!
I have no explanation as why genfstab generated those permissions on my end 
I haven’t changed them myself. That’s for sure.
Nothing jumps at me at a first glance but you have still these:
Jan 28 11:26:05 ryzen bootctl[759]: ! Mount point '/efi' which backs the random seed file is world accessible, which is a security hole! !
Jan 28 11:26:05 ryzen bootctl[759]: ! Random seed file '/efi/loader/random-seed' is world accessible, which is a security hole! !
Jan 28 11:26:06 ryzen systemd-logind[783]: /efi/loader/loader.conf:5: Unknown line 'reboot-for-bitlocker', ignoring.
If mounting your /home partition gives you more issues in the continuation as was shown in the picture you posted, consider running a disk health check on that NVME drive:
I think genfstab has no AI and would not know that /boot/efi is the ESP partition, maybe a normal partition, and then it generates a line of vfat with fmask=0022,dmask=0022 to allow other users to access files and directories.
Could be.
/boot/efi is not where Arch actually recommends to mount ESP either.
The recommendation is /boot or /efi.
So your explanation is plausible.
This is my smarctl --info for /home device
sudo smartctl --info /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.14-1-lts] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 980 PRO 1TB
Serial Number: S5GXNL0W407287A
Firmware Version: 5B2QGXA7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 1.000.204.886.016 [1,00 TB]
Unallocated NVM Capacity: 0
Controller ID: 6
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 1.000.204.886.016 [1,00 TB]
Namespace 1 Utilization: 641.254.617.088 [641 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 b431a6b43e
Local Time is: Sun Jan 28 11:54:48 2024 CET
and smartctl -c
sudo smartctl -c /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.14-1-lts] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0057): Comp Wr_Unc DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x0f): S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg
Maximum Data Transfer Size: 128 Pages
Warning Comp. Temp. Threshold: 82 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 8.49W - - 0 0 0 0 0 0
1 + 4.48W - - 1 1 1 1 0 200
2 + 3.18W - - 2 2 2 2 0 1000
3 - 0.0400W - - 3 3 3 3 2000 1200
4 - 0.0050W - - 4 4 4 4 500 9500
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
1 Like
Run:
sudo smartctl -d nvme,0xffffffff -t short /dev/nvme1n1
to run a short test. Wait a couple of minutes till it is done.
Run:
sudo smartctl -l selftest /dev/nvme1n1
to get a list of recent tests.
Check with:
sudo smartctl -x /dev/nvme1n1
to show detailed information.
Or just for a short health check assessment:
sudo smartctl -H /dev/nvme1n1
➜ sudo smartctl -l selftest /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.14-1-lts] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
Read Self-test Log failed: Invalid Field in Command (0x002)
Does that mean selftest isnt finished?
sudo smartctl -x /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.14-1-lts] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 980 PRO 1TB
Serial Number: S5GXNL0W407287A
Firmware Version: 5B2QGXA7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 1.000.204.886.016 [1,00 TB]
Unallocated NVM Capacity: 0
Controller ID: 6
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 1.000.204.886.016 [1,00 TB]
Namespace 1 Utilization: 641.256.398.848 [641 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 b431a6b43e
Local Time is: Sun Jan 28 12:24:14 2024 CET
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0057): Comp Wr_Unc DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x0f): S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg
Maximum Data Transfer Size: 128 Pages
Warning Comp. Temp. Threshold: 82 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 8.49W - - 0 0 0 0 0 0
1 + 4.48W - - 1 1 1 1 0 200
2 + 3.18W - - 2 2 2 2 0 1000
3 - 0.0400W - - 3 3 3 3 2000 1200
4 - 0.0050W - - 4 4 4 4 500 9500
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 32 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 21.852.617 [11,1 TB]
Data Units Written: 10.631.340 [5,44 TB]
Host Read Commands: 111.247.659
Host Write Commands: 128.790.438
Controller Busy Time: 943
Power Cycles: 314
Power On Hours: 190
Unsafe Shutdowns: 16
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 32 Celsius
Temperature Sensor 2: 36 Celsius
Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged
Read Self-test Log failed: Invalid Field in Command (0x002)
sudo smartctl -H /dev/nvme1n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.14-1-lts] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
It seems drive is fully functionally.
Yes. Looks good.
The issue with the failing dependency for /home might have been due to some filesystem corruption or inconsistency. Hopefully running the check from the live usb has fixed it.
My bad. It should have been:
sudo smartctl -d nvme,0xffffffff -l selftest /dev/nvme1n1
as you are running KDE, you can also check kinfocenter → Devices → SMART Status for drive health
What does a poor GNOME user know of such KDE subtleties? 
It seems that my drive is completely ok. I think the check from the live USB hopefully helped
Now i should fix this error:
ryzen bootctl[758]: ! Mount point '/efi' which backs the random seed file is world accessible, which is a security hole! !
ryzen bootctl[758]: ! Random seed file '/efi/loader/random-seed' is world accessible, which is a security hole!
is it sufficient to edit the fstab as follows? Did I understand this correctly?
UUID=D3E2-C3D4 /efi vfat defaults,noatime,umask=0077 0 2
Can I reload the fstab with which command? or is it only relevant with a restart?
1 Like
Yes.
sudo systemctl daemon-reload
and then:
sudo mount -a
Also look into this.
As I mentioned before, I couldn’t see any reference to reboot-for-bitlocker in man loader.conf.
Not sure if this is added by EnOS’ for those dualbooting with Windows
At any rate, I think in your case, it should be safe to remove it (or at least commenting it out).
I got this error message
➜ LANG=C sudo mount -a
mount: 0: unknown filesystem type '0'.
dmesg(1) may have more information after failed mount system call.
Does sudo findmnt --verify give more info?