Yes.
You can start with running a full fsck on all of your ext4 partitions from a live USB session, but — and this is important! — without mounting them, let alone chroot’ing.
However, this sort of thing normally doesn’t happen out of the blue, so there is a possibility that the drive itself or the PCIe slot it is plugged into would be malfunctioning.
You will need to keep monitoring the situation. 
This is likely as it seems the filesystem is corrupted. You should run fsck from a Live session (but not in a CHROOT environment):
sudo fsck -f /dev/nvme0n1p4
… and it also wouldn’t hurt to run a SMART check:
sudo smartctl -a /dev/nvme0n1
(You need to have smartmontools installed to run this).
Hehe you replied while I was tripe-ing™ … 
Thank you @Aragorn and @BG405,
smartmontools reports averything OK, but I’m confused
So chroot or NOT chroot?
And: In case a former check and repair using gParted may have removed some data, is it worth to restore /home/Username from an rsync-backup? If so, how?
Don’t chroot! This will mount the partition(s) you need to check.
They need to remain unmounted.
As far as rsync, I’ve never used it so can’t advise; however, if the storage is actually OK, then this may be an option.
What errors did gparted report?
NOT chroot.
As he said …
Just boot from USB and run
or whatever the partition in question is.
The partition to be checked can’t be mounted.
That should not happen.
(and why would you want to use gparted ? - fsck is quite adequate for the job …
it actually is THE tool for the job …)
In any case:
That is only an option after you made sure that the file system holding the data is o.k.
Counter question:
How would you determine whether anything was “removed”?
The result of the fsck will give you a clue …
… an rsync backup creates a 1:1 copy of the contents of the file system at that time.
You can simply copy from one to the other - or use rsync again to restore the previous state.
But only after you know that the file system itself is o.k.
ps:
restoring (or not) your /home directory will not solve your problem, which appears to be that your Desktop or your display manager doesn’t even start.
The /home directory is not where this (possible) problem is located.
…
I’ll ask once again - for the third and last time
re your /etc/fstab
Is the directory /media
to which you try to mount several things
…
is it even present?
… because:
it will not even be there
if you do not create it first
No chroot. The filesystems may not even be mounted, or else fsck will cause even greater damage! 
For that, you need to mount the /home filesystem, and the one holding the backups.
Assuming that you’re working from the live USB — as you should! — first mount your /home at /mnt. 
sudo mount -t ext4 /dev/nvme0n1p4 /mnt/
Then, you need to create a mountpoint for the volume with the backups. As I don’t know what volume that is, I will use /dev/sdb1 in the example below — adjust as required.
sudo mkdir /backups
sudo mount -t ext4 /dev/sdb1 /backups/
cp -RPpv /backups/timeshift/snapshots/<time-of-last-backup>/localhost/home/* /mnt/ && sync
I suppose you misunderstood one of those comments you quoted; but, they both say not to use chroot. 
Instead, perform fsck from the terminal of the Live USB.
Now, I’ll ride off into the sunset, one more time. 
This is what I did so far: Running MANJARO from an USB-Stick:
$ sudo fsck -f /dev/nvme0n1p4 ✔
fsck from util-linux 2.41.1
e2fsck 1.47.3 (8-Jul-2025)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
home: 157394/2097152 files (7.8% non-contiguous), 4452652/8388608 blocks
$ sudo smartctl -a /dev/nvme0n1p4 INT ✘
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.12.37-1-MANJARO] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 970 EVO Plus 2TB
Serial Number: S4J4NZFN904794Z
Firmware Version: 2B2QEXM7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 2.000.398.934.016 [2,00 TB]
Unallocated NVM Capacity: 0
Controller ID: 4
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 2.000.398.934.016 [2,00 TB]
Namespace 1 Utilization: 1.877.645.221.888 [1,87 TB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 59019d7436
Local Time is: Tue Aug 5 13:38:07 2025 UTC
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x03): S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size: 512 Pages
Warning Comp. Temp. Threshold: 85 Celsius
Critical Comp. Temp. Threshold: 85 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 7.50W - - 0 0 0 0 0 0
1 + 5.90W - - 1 1 1 1 0 0
2 + 3.60W - - 2 2 2 2 0 0
3 - 0.0700W - - 3 3 3 3 210 1200
4 - 0.0050W - - 4 4 4 4 2000 8000
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, NSID 0x1)
Critical Warning: 0x00
Temperature: 30 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 1%
Data Units Read: 95.641.327 [48,9 TB]
Data Units Written: 87.063.097 [44,5 TB]
Host Read Commands: 726.870.544
Host Write Commands: 843.822.251
Controller Busy Time: 2.670
Power Cycles: 10.451
Power On Hours: 2.508
Unsafe Shutdowns: 97
Media and Data Integrity Errors: 0
Error Information Log Entries: 11.235
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 30 Celsius
Temperature Sensor 2: 25 Celsius
Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS Message
0 11235 0 0x0008 0x4004 - 0 0 - Invalid Field in Command
Self-test Log (NVMe Log 0x06, NSID 0xffffffff)
Self-test status: No self-test in progress
No Self-tests Logged
My apologies @Nachlese if missed something:
I had shown the reduced /etc/fstab here and it is still like this.
Yes, I’m mounting several thins to /media. All devices mounted like that can be accessed without any issue.
Yes, /media is present:
insgesamt 296
drwxr-xr-x 18 root root 4096 18. Mai 11:07 .
drwxr-xr-x 18 root root 4096 18. Mai 11:07 ..
lrwxrwxrwx 1 root root 7 8. Mai 02:57 bin -> usr/bin
drwxr-xr-x 5 root root 4096 3. Aug 18:00 boot
-rw-r--r-- 1 root root 23351 19. Okt 2020 desktopfs-pkgs.txt
drwxr-xr-x 20 root root 4420 5. Aug 16:03 dev
drwxr-xr-x 125 root root 12288 5. Aug 16:03 etc
-rw-r--r-- 1 root root 169993 27. Apr 2021 file
drwxr-xr-x 4 root root 4096 7. Nov 2020 home
lrwxrwxrwx 1 root root 7 8. Mai 02:57 lib -> usr/lib
lrwxrwxrwx 1 root root 7 8. Mai 02:57 lib64 -> usr/lib
drwx------ 2 root root 16384 7. Nov 2020 lost+found
-rw-r--r-- 1 root root 7 19. Okt 2020 .manjaro-tools
drwxr-xr-x 8 root root 4096 21. Feb 2023 media
drwxr-xr-x 3 root root 4096 7. Nov 2020 mnt
drwxr-xr-x 11 root root 4096 10. Mai 08:08 opt
dr-xr-xr-x 365 root root 0 5. Aug 16:02 proc
drwxr-x--- 9 root root 4096 16. Mai 08:26 root
-rw-r--r-- 1 root root 5218 19. Okt 2020 rootfs-pkgs.txt
drwxr-xr-x 35 root root 860 5. Aug 16:46 run
lrwxrwxrwx 1 root root 7 8. Mai 02:57 sbin -> usr/bin
drwxr-xr-x 4 root root 4096 19. Okt 2020 srv
dr-xr-xr-x 13 root root 0 5. Aug 16:46 sys
drwxrwxrwt 14 root root 300 5. Aug 16:46 tmp
drwxr-xr-x 9 root root 4096 4. Aug 13:28 usr
drwxr-xr-x 12 root root 4096 4. Aug 13:32 var
My next step would be the message from @Aragorn (copy /home/myname from backup); any objections?
What I’d do is copy the current /home to somewhere safe (particularly the .dotfiles where you might have some more recent emails stored, etc.) & then restore from your backup. 
However, this might be part of the issue:
… leading to accumulating corruption, quite likely.
looking at the inxi output above, it looks like you are almost out of space on your disk, which can cause not to boot…
run these:
sudo pacman -Scc
sudo journalctl --rotate
sudo journalctl -m --vacuum-time=1s
and see if it helped…
To save anyone from having to scroll up. 
I clicked Solution accidentally instead of the Like button (breaking in a new mouse) - apologies for any potential confusion. 
oh oh …
@MaMicha
To mitigate that situation, you could and probably should clear out the package cache:
sudo pacman -Scc
or
sudo rm -rf /var/cache/pacman/pkg/*
(the effect is the same for both commands)
Another way to give anyone but root more space without deleting anything is:
sudo tune2fs -m 1 /dev/nvme0n1p3
It lowers the reserved for root only space from 5% (default) to 1%
(for your /home partition you should even set that value to 0 - no point in having reserved space for root there)
Try these steps first.
Check results by rebooting.
If nothing changed, continue here:
You have now (several posts ago) altered your display manager configuration.
Do not forget that you did.
It didn’t seem to have the desired effect.
For that reason alone I’d reverse the changes you made in:
/etc/sddm.conf.d/kde_settings.conf
… it did work before, no reason to assume why it would not work now with the very same settings.
Next I’d stop or even disable the display manager
and (try to) start the session “by hand”
From a TTY:
log in as your user - not as root
systemctl stop sddm.service
startx
What happens?
Thank you @brahma:
From virtual konsole I run:
sudo pacman -Scc
Directory: /var/cache/pacman/pkg
ERROR: unable to remove /var/cache/pacman/pkg/download-zI20ay, is a directory
Should I remove it manually?
sudo journalctl --rotate
sudo journalctl -m --vacuum-time=1s
Done, freed 430,2 M …
After which period do you recommend to run these commands?
For a new setup on a machine I’m expecting, which size do you recommend for this partition?
Unfortunately, the issue persists.
There should be a timer that does that automatically, periodically.
You should not need to do that “by hand” - but it did free up some space (~430 MB it seems).
Not a lot.
You should check the result by looking at how much free space you have now, after running these commands.
df -h
You where tight on space - see how it looks now.
32 GB for / (root) is sufficient - if you don’t install snaps or flatpacks.
They use a lot of space.
I gets tight really quickly.
Just remove it, including it’s contents.
It’s something pamac created - pacman only removes files from the cache.
It doesn’t expect to see directories inside it’s cache …
… on you go with what I said in my comment above? 
Or wait for input from @brahma
when running the pacman -Scc, and you are prompted, then yes to all…
so run it again…
also uninstall tlp:
sudo pacman -R tlp
if it doesnt help, i really dont know what else to try, except switch to the testing branch and see if that helps:
sudo pacman-mirrors --api --set-branch testing && sudo pacman-mirrors --fasttrack 5 && sudo pacman -Syyu
and dont forget this:
Thank you @brahma and @Nachlese and @Aragorn,
Done, from virtual konsole.
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
dev 16G 0 16G 0% /dev
run 16G 1,8M 16G 1% /run
efivarfs 156K 50K 102K 33% /sys/firmware/efi/efivars
/dev/nvme0n1p3 32G 21G 8,8G 71% /
tmpfs 16G 1,1M 16G 1% /dev/shm
tmpfs 1,0M 0 1,0M 0% /run/credentials/systemd-journald.service
tmpfs 16G 0 16G 0% /tmp
/dev/nvme0n1p1 511M 18M 494M 4% /boot/efi
/dev/nvme0n1p4 32G 17G 14G 55% /home
/dev/nvme0n1p7 1,2T 1,2T 15G 99% /mnt/Daten
/dev/nvme0n1p5 295G 277G 3,1G 99% /home/hessler/VirtualBoxVMs
tmpfs 1,0M 0 1,0M 0% /run/credentials/getty@tty2.service
tmpfs 3,1G 64K 3,1G 1% /run/user/1000
//XYZ-X240/X240-Daten 706G 701G 5,1G 100% /media/XYZ-X240
My next steps will be:
and
Due to other obligations, this will be not earlier than Thursday, 07.05.2025.
and what are these packages that you have installed? they look sus to me… where did you installed them from?
o.k.
now it’s definitely not down to space constraints …
I’m getting way too invested in this.
It perhaps continues two days from now … good luck!
Official download pages, f.e. libreoffice. As I’m using LibreOffice BASE quite a lot, I have been advised to run the original packages, not the ones from the distributions. They are stored in /opt and have been running before the issue without any problem.