All files from user directory vanished in a sudden

Ask Fedora
, , ,
1

Hi,

i was editing ID-tags from music files with Kid3, at first with no problems on a laptop, then some files on a music player connected via USB-C (which was very slow and juddery while saving; before that an external SSD connected also via USB unusually took three tries to appear on the desktop, just remembered that).

Suddenly couldn’t save or edit anymore, Kid3 hang, desktop was cleared from files and folders and view settings were reseted (trash and disk icon appeared in the upper left corner, panels were cleared). Opening a window showed me all files and directories of user account were gone! Except the default directories Pictures, Applications… which were newly created, according to creation date. It’s like the user account was reseted. 450 GB of formerly used disk space were free now, a complete of 981 GB is now unused. I’m in disbelief.

System is Fedora 38, Cinnamon, BTRFS, Dell XPS, a few months old 1000 GB SSD (Crucial MX500)

I’ve set this Notebook up two months ago, so i “luckily” have a backup from there, but in between files changed a lot, e.g. lots of edited and sorted raw images, collected information etc… I was sorting the last things to make a new backup this weekend.

System runs, unlocking LUKS and user-login works with no problems. As only user directory seems to be affected, this seems to be constrained by ownership/permissions (thus no hardware failure of disk).

Tried to fix with fedora-live-system, gparted-live-system, fsck, e2fsck, mke2fs, gparted, (and cryptsetup for unlocking), now i know that btfrs is the default FS on Fedora 38 (i have used ext4 on my older laptop until now), checked it, indeed btrfs on the new notebook. So i tried fixing FS with btrfs-progs, no success.

e2fsck on the encrypted volume tells me a superblock is invalid, btrfs rescue super-recover says all supers are valid, btrfs restore finds nothing, photorec and testdisk didn’t help. I didn’t use btrfs check --repair but at last resort i would.

As there is a lot of data on this disk and i spent long time trying fixing i would really appreciate any help.

Also it would be interesting to know what can cause something of this quality. Just an USB device wrecking a progressive file system so bad? I use Fedora since Heisenbug and never lost data due to system failure, could that vulnerability be related to btrfs? This is strongly concerning.

PS: One of my first attempts was a sudo mke2fs -n /dev/sda3 on the encrypted partition, output was:
→ partition is encrypted, proceed anyway y/n? → i said “y”. Hope that was no big mistake. Anyway user directories are the same as directly after the crash, did a dd clone right after that.

journalctl


Okt 27 18:21:10 fedora systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Okt 27 18:21:10 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispat>
Okt 27 18:30:07 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
Okt 27 18:30:07 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:08 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
Okt 27 18:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:08 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
Okt 27 18:30:08 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:09 fedora kernel: usb 1-1: device not accepting address 16, error -71
Okt 27 18:30:09 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
Okt 27 18:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:09 fedora kernel: usb 1-1: device not accepting address 16, error -71
Okt 27 18:30:09 fedora kernel: usb 1-1: USB disconnect, device number 16
Okt 27 18:30:10 fedora kernel: usb 1-1: new high-speed USB device number 17 using xhci_hcd
Okt 27 18:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:10 fedora kernel: usb 1-1: new high-speed USB device number 18 using xhci_hcd
Okt 27 18:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:11 fedora kernel: usb 1-1: device descriptor read/64, error -32
Okt 27 18:30:11 fedora kernel: usb usb1-port1: attempt power cycle
Okt 27 18:30:11 fedora kernel: usb 1-1: new high-speed USB device number 19 using xhci_hcd
Okt 27 18:30:11 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:11 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:11 fedora kernel: usb 1-1: device not accepting address 19, error -71
Okt 27 18:30:12 fedora kernel: usb 1-1: new high-speed USB device number 20 using xhci_hcd
Okt 27 18:30:12 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:12 fedora kernel: usb 1-1: Device not responding to setup address.
Okt 27 18:30:12 fedora kernel: usb 1-1: device not accepting address 20, error -71
Okt 27 18:30:12 fedora kernel: usb usb1-port1: unable to enumerate USB device
Okt 27 18:30:12 fedora udisksd[1821]: Cleaning up mount point /run/media/fedora/FDB0-7FF3 (device 8:16 no longer exists)
Okt 27 18:30:12 fedora systemd[1]: run-media-fedora-FDB0\x2d7FF3.mount: Deactivated successfully.
Okt 27 18:30:41 fedora kernel: usb 1-1: new high-speed USB device number 21 using xhci_hcd
Okt 27 18:30:41 fedora kernel: usb 1-1: New USB device found, idVendor=0525, idProduct=a4a5, bcdDevice= 0.00
Okt 27 18:30:41 fedora kernel: usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=0
Okt 27 18:30:41 fedora kernel: usb 1-1: Product: Mass Storage Gadget
Okt 27 18:30:41 fedora kernel: usb 1-1: Manufacturer: Linux 3.10.14-svn302 with dwc2-gadget
Okt 27 18:30:41 fedora kernel: usb-storage 1-1:1.0: USB Mass Storage device detected
Okt 27 18:30:41 fedora kernel: usb-storage 1-1:1.0: Quirks match for vid 0525 pid a4a5: 10000
Okt 27 18:30:41 fedora kernel: scsi host3: usb-storage 1-1:1.0
Okt 27 18:30:41 fedora mtp-probe[37097]: checking bus 1, device 21: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Okt 27 18:30:41 fedora mtp-probe[37097]: bus: 1, device: 21 was not an MTP device
Okt 27 18:30:41 fedora mtp-probe[37103]: checking bus 1, device 21: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Okt 27 18:30:41 fedora mtp-probe[37103]: bus: 1, device: 21 was not an MTP device
Okt 27 18:30:42 fedora kernel: scsi 3:0:0:0: Direct-Access     Linux    File-CD Gadget   0331 PQ: 0 ANSI: 2
Okt 27 18:30:42 fedora kernel: sd 3:0:0:0: Attached scsi generic sg1 type 0
Okt 27 18:30:42 fedora kernel: sd 3:0:0:0: Power-on or device reset occurred
Okt 27 18:30:42 fedora kernel: sd 3:0:0:0: [sdb] 31113216 512-byte logical blocks: (15.9 GB/14.8 GiB)
Okt 27 18:30:43 fedora kernel: sd 3:0:0:0: [sdb] Write Protect is off
Okt 27 18:30:43 fedora kernel: sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
Okt 27 18:30:43 fedora kernel: sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Okt 27 18:30:43 fedora kernel:  sdb:
Okt 27 18:30:43 fedora kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Okt 27 18:30:43 fedora udisksd[1821]: Mounted /dev/sdb at /run/media/fedora/FDB0-7FF3 on behalf of uid 1000
Okt 27 18:30:43 fedora kernel: FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Okt 27 18:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "h"
Okt 27 18:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "help-all"
Okt 27 18:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "v"
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:02 fedora kernel: nouveau 0000:01:00.0: Enabling HDA controller
Okt 27 18:31:03 fedora kid3[37152]: kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Your emails" msgid_plural: "" msgctxt: "EMAIL>
Okt 27 18:31:03 fedora kid3[37152]: kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Your names" msgid_plural: "" msgctxt: "NAME O>
Okt 27 18:31:03 fedora kid3[37152]: kf.xmlgui: Shortcut for action  "open_directory" "&Ordner öffnen ..." set with QAction::setShortcut()! Use KActionCol>
Okt 27 18:31:03 fedora kid3[37152]: kf.xmlgui: Shortcut for action  "reload" "&Neu laden" set with QAction::setShortcut()! Use KActionCollection::setDefa>
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
Okt 27 18:34:10 fedora appimagelauncherd[2094]: Scheduling for unintegration: /home/fedora/Programme/brother
...
Okt 27 18:34:12 fedora appimagelauncherd[2094]: Scheduling for unintegration: /home/fedora/Programme/Maperitive
Okt 27 18:34:13 fedora audit[2094]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2094 comm>
Okt 27 18:34:13 fedora kernel: traps: appimagelaunche[2094] general protection fault ip:7fcb522cd424 sp:7ffdf122b638 error:0 in libstdc++.so.6.0.32[7fcb5>
Okt 27 18:34:13 fedora audit: BPF prog-id=136 op=LOAD
Okt 27 18:34:13 fedora audit: BPF prog-id=137 op=LOAD
Okt 27 18:34:13 fedora audit: BPF prog-id=138 op=LOAD
Okt 27 18:34:13 fedora systemd[1]: Started systemd-coredump@1-37238-0.service - Process Core Dump (PID 37238/UID 0).
Okt 27 18:34:13 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@1-3>
Okt 27 18:34:14 fedora abrt-dump-journal-oops[1907]: abrt-dump-journal-oops: Found oopses: 1
Okt 27 18:34:14 fedora abrt-dump-journal-oops[1907]: abrt-dump-journal-oops: Creating problem directories
Okt 27 18:34:15 fedora abrt-server[37241]: Can't find a meaningful backtrace for hashing in '.'
Okt 27 18:34:15 fedora abrt-server[37241]: Deleting non-reportable oops '.' because DropNotReportableOopses is set to 'yes'
Okt 27 18:34:15 fedora abrt-server[37241]: 'post-create' on '/var/spool/abrt/oops-2023-10-27-20:34:14-1907-0' exited with 1
Okt 27 18:34:15 fedora abrt-server[37241]: Deleting problem directory '/var/spool/abrt/oops-2023-10-27-20:34:14-1907-0'
Okt 27 18:34:15 fedora abrt-server[37241]: Lock file '.lock' was locked by process 37253, but it crashed?
Okt 27 18:34:15 fedora abrt-dump-journal-oops[1907]: Reported 1 kernel oopses to Abrt
Okt 27 18:34:49 fedora systemd-coredump[37239]: [🡕] Process 2094 (appimagelaunche) of user 1000 dumped core.
                                                
                                                Module libdatrie.so.1 from rpm libdatrie-0.2.13-5.fc38.x86_64

dmesg

 
             Oct 27 20:21:10 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
               Oct 27 20:30:07 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
               Oct 27 20:30:07 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:08 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
               Oct 27 20:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:08 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:08 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
               Oct 27 20:30:08 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:09 fedora kernel: usb 1-1: device not accepting address 16, error -71
               Oct 27 20:30:09 fedora kernel: usb 1-1: reset high-speed USB device number 16 using xhci_hcd
               Oct 27 20:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:09 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:09 fedora kernel: usb 1-1: device not accepting address 16, error -71
               Oct 27 20:30:09 fedora kernel: usb 1-1: USB disconnect, device number 16
               Oct 27 20:30:10 fedora kernel: usb 1-1: new high-speed USB device number 17 using xhci_hcd
               Oct 27 20:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:10 fedora kernel: usb 1-1: new high-speed USB device number 18 using xhci_hcd
               Oct 27 20:30:10 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:11 fedora kernel: usb 1-1: device descriptor read/64, error -32
               Oct 27 20:30:11 fedora kernel: usb usb1-port1: attempt power cycle
               Oct 27 20:30:11 fedora kernel: usb 1-1: new high-speed USB device number 19 using xhci_hcd
               Oct 27 20:30:11 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:11 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:11 fedora kernel: usb 1-1: device not accepting address 19, error -71
               Oct 27 20:30:12 fedora kernel: usb 1-1: new high-speed USB device number 20 using xhci_hcd
               Oct 27 20:30:12 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:12 fedora kernel: usb 1-1: Device not responding to setup address.
               Oct 27 20:30:12 fedora kernel: usb 1-1: device not accepting address 20, error -71
               Oct 27 20:30:12 fedora kernel: usb usb1-port1: unable to enumerate USB device
               Oct 27 20:30:12 fedora udisksd[1821]: Cleaning up mount point /run/media/fedora/FDB0-7FF3 (device 8:16 no longer exists)
               Oct 27 20:30:12 fedora systemd[1]: run-media-fedora-FDB0\x2d7FF3.mount: Deactivated successfully.
               Oct 27 20:30:41 fedora kernel: usb 1-1: new high-speed USB device number 21 using xhci_hcd
               Oct 27 20:30:41 fedora kernel: usb 1-1: New USB device found, idVendor=0525, idProduct=a4a5, bcdDevice= 0.00
               Oct 27 20:30:41 fedora kernel: usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=0
               Oct 27 20:30:41 fedora kernel: usb 1-1: Product: Mass Storage Gadget
               Oct 27 20:30:41 fedora kernel: usb 1-1: Manufacturer: Linux 3.10.14-svn302 with dwc2-gadget
               Oct 27 20:30:41 fedora kernel: usb-storage 1-1:1.0: USB Mass Storage device detected
               Oct 27 20:30:41 fedora kernel: usb-storage 1-1:1.0: Quirks match for vid 0525 pid a4a5: 10000
               Oct 27 20:30:41 fedora kernel: scsi host3: usb-storage 1-1:1.0
               Oct 27 20:30:41 fedora mtp-probe[37097]: checking bus 1, device 21: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
               Oct 27 20:30:41 fedora mtp-probe[37097]: bus: 1, device: 21 was not an MTP device
               Oct 27 20:30:41 fedora mtp-probe[37103]: checking bus 1, device 21: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
               Oct 27 20:30:41 fedora mtp-probe[37103]: bus: 1, device: 21 was not an MTP device
               Oct 27 20:30:42 fedora kernel: scsi 3:0:0:0: Direct-Access     Linux    File-CD Gadget   0331 PQ: 0 ANSI: 2
               Oct 27 20:30:42 fedora kernel: sd 3:0:0:0: Attached scsi generic sg1 type 0
               Oct 27 20:30:42 fedora kernel: sd 3:0:0:0: Power-on or device reset occurred
               Oct 27 20:30:42 fedora kernel: sd 3:0:0:0: [sdb] 31113216 512-byte logical blocks: (15.9 GB/14.8 GiB)
               Oct 27 20:30:43 fedora kernel: sd 3:0:0:0: [sdb] Write Protect is off
               Oct 27 20:30:43 fedora kernel: sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
               Oct 27 20:30:43 fedora kernel: sdb:
               Oct 27 20:30:43 fedora kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
               Oct 27 20:30:43 fedora udisksd[1821]: Mounted /dev/sdb at /run/media/fedora/FDB0-7FF3 on behalf of uid 1000
               Oct 27 20:30:43 fedora kernel: FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
               Oct 27 20:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "h"
               Oct 27 20:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "help-all"
               Oct 27 20:31:01 fedora kid3[37152]: QCommandLineParser: already having an option named "v"
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:01 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:02 fedora kernel: nouveau 0000:01:00.0: Enabling HDA controller
               Oct 27 20:31:03 fedora kid3[37152]: kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Your emails" msgid_plural: "" msgctxt: "EMAIL OF TRANSLATORS"
               Oct 27 20:31:03 fedora kid3[37152]: kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Your names" msgid_plural: "" msgctxt: "NAME OF TRANSLATORS"
               Oct 27 20:31:03 fedora kid3[37152]: kf.xmlgui: Shortcut for action  "open_directory" "&Ordner öffnen ..." set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
               Oct 27 20:31:03 fedora kid3[37152]: kf.xmlgui: Shortcut for action  "reload" "&Neu laden" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:31:09 fedora kernel: ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20230331/exsystem-141)
               Oct 27 20:34:10 fedora appimagelauncherd[2094]: Scheduling for unintegration: /home/fedora/Programme/brother
				...
               Oct 27 20:34:12 fedora appimagelauncherd[2094]: Scheduling for unintegration: /home/fedora/Programme/Maperitive
               Oct 27 20:34:13 fedora audit[2094]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2094 comm="appimagelaunche" exe="/usr/bin/appimagelauncherd" sig=11 res=1
               Oct 27 20:34:13 fedora kernel: traps: appimagelaunche[2094] general protection fault ip:7fcb522cd424 sp:7ffdf122b638 error:0 in libstdc++.so.6.0.32[7fcb5229c000+12a000]
               Oct 27 20:34:13 fedora audit: BPF prog-id=136 op=LOAD
               Oct 27 20:34:13 fedora audit: BPF prog-id=137 op=LOAD
               Oct 27 20:34:13 fedora audit: BPF prog-id=138 op=LOAD
               Oct 27 20:34:13 fedora systemd[1]: Started systemd-coredump@1-37238-0.service - Process Core Dump (PID 37238/UID 0).
               Oct 27 20:34:13 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@1-37238-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
               Oct 27 20:34:14 fedora abrt-dump-journal-oops[1907]: abrt-dump-journal-oops: Found oopses: 1
               Oct 27 20:34:14 fedora abrt-dump-journal-oops[1907]: abrt-dump-journal-oops: Creating problem directories
               Oct 27 20:34:15 fedora abrt-server[37241]: Can't find a meaningful backtrace for hashing in '.'
               Oct 27 20:34:15 fedora abrt-server[37241]: Deleting non-reportable oops '.' because DropNotReportableOopses is set to 'yes'
               Oct 27 20:34:15 fedora abrt-server[37241]: 'post-create' on '/var/spool/abrt/oops-2023-10-27-20:34:14-1907-0' exited with 1
               Oct 27 20:34:15 fedora abrt-server[37241]: Deleting problem directory '/var/spool/abrt/oops-2023-10-27-20:34:14-1907-0'
               Oct 27 20:34:15 fedora abrt-server[37241]: Lock file '.lock' was locked by process 37253, but it crashed?
               Oct 27 20:34:15 fedora abrt-dump-journal-oops[1907]: Reported 1 kernel oopses to Abrt
               Oct 27 20:34:49 fedora systemd-coredump[37239]: Process 2094 (appimagelaunche) of user 1000 dumped core.#012#012Module

For some reason journalctl und dmesg have a 2-hour-difference in the timecode

2

Please tell us where the files seem to have disappeared.
Are you using the gui file manager?
Are you using the command line with “ls”?
Have you tried using the command line ls -al in your users home directory?

We need to know exactly what you have tried or not tried to even be able to troubleshoot this.

As far as time in journalctl, it normally records in local time. Dmesg only reports in second since last boot unless you use an option. Thus it is important that you show the actual command used with all options. From the man page for dmesg it tells me

       -e, --reltime
           Display the local time and the delta in human-readable format. Be aware that conversion to the local time could be
           inaccurate (see -T for more details).

      -T, --ctime
           Print human-readable timestamps.

           Be aware that the timestamp could be inaccurate! The time source used for the logs is not updated after system
           SUSPEND/RESUME. Timestamps are adjusted according to current delta between boottime and monotonic clocks, this works
           only for messages printed after last resume.

Thus time may easily be differing since one is adjusted based on runtime for the current boot and the other is based on actual calendar time related to UTC with no adjustments.

I suggest you remove all gui tools from the problem and first test using the cli tools. Once that is solved or confirmed working then the problem may be isolated to an app that is not working.

Also, it may be appropriate to do a full selinux context restore of the entire file system by doing sudo restorecon -R / and keep the system on and running until it completes. This may take some time depending upon the file system size and the amount of data it contains.

3

sudo restorecon -R / unfortunaly changed nothing, it needed about three minutes.

Ok, in detail:
At first i saw all files disappeared from desktop, then i checked the rest of my directories with Nemo (GUI) and later on the live-gparted-system (on a USB-Stick) with ls -al and ls -R in the user directory (which was a short list). For the recovery i used terminal only, please see below.

In fact the whole process was not that straight foward as i had to learn and try, but in the end i tried all that:

When booted from live-system

lsblk
→ sda3 was the only disk with 929 GB thus the right one

sudo cryptsetup luksOpen /dev/sda3 decdev
sudo mkdir /media/baddisk
sudo mount /dev/mapper/decdev /media/baddisk → should have been better be mounted read-only
cd /media/baddisk/home/fedora/
ls -al
and
ls -R

ls -al
insgesamt 32
drwx------. 1 fedora fedora 268 30. Okt 22:15 .
drwxr-xr-x. 1 root root 12 19. Jan 2023 …
-rw-------. 1 fedora fedora 0 29. Okt 10:02 .bash_history
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Bilder
drwx------. 1 fedora fedora 194 29. Okt 10:04 .cache
drwxr-xr-x. 1 fedora fedora 408 29. Okt 10:09 .config
drwxr-xr-x. 1 fedora fedora 60 29. Okt 10:09 Dokumente
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Downloads
drwxr-xr-x. 1 fedora fedora 20 27. Okt 20:46 .local
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Musik
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Öffentlich
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:34 Schreibtisch
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Videos
drwxr-xr-x. 1 fedora fedora 0 27. Okt 20:44 Vorlagen
-rw-------. 1 fedora fedora 8757 30. Okt 22:24 .xsession-errors
-rw-------. 1 fedora fedora 17188 29. Okt 10:09 .xsession-errors.old

logfiles
timecode from journalctl is two hours back, crash was at 20.30 (8.30 pm), timecode from dmesg is correct
cd /media/baddisk/root/var/log/
sudo journalctl --since "2023-10-27 18:20:00" -D journal
sudo dmesg -F "messages-20231029"

sudo umount /media/baddisk
sudo cryptsetup luksClose decdev
sudo e2fsck /dev/sda3
ext2fs_open2: Bad magic number in super-block.
e2fsck: Superblock invalid, trying backup superblocks
e2fsck: Bad magic number in super-block while trying to open /dev/sda3
superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem
…

sudo mke2fs -n /dev/sda3
/dev/sda3 contains a crypto_LUKS file system, proceed anyway? (y,N)
y → option -n causes mke2fs only to display what it would do, so nothing bad should be happened here

sudo cryptsetup luksOpen /dev/sda3 decdev
sudo mount /dev/mapper/decdev /media/baddisk
df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
…
/dev/sdc4 ext4 960302796 24281256 887167524 3% /media/backupdisk
/dev/mapper/decdev btrfs 975081472 13892036 958314492 2% /media/baddisk

sudo umount /media/baddisk

sudo btrfs rescue super-recover /dev/mapper/decdev
All supers are valid, no need to recover

sudo btrfs check /dev/mapper/decdev
Opening filesystem to check…
Checking filesystem on /dev/mapper/decdev
UUID: bc57e142-263c-4509-8a5a-9568534d2d65
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 13511430144 bytes used, no error found
total csum bytes: 12525040
total tree bytes: 654835712
total fs tree bytes: 595591168
total extent tree bytes: 37634048
btree space waste bytes: 135167025
file data blocks allocated: 36775931904
referenced 22631260160

sudo btrfs-find-root /dev/mapper/decdev
Superblock thinks the generation is 21253
Superblock thinks the level is 0
Found tree root at 30670848 gen 21253 level 0
Well block 30425088(gen: 21252 level: 0) seems good, but generation/level doesn’t match, want gen: 21253 level: 0

sudo btrfs restore /dev/mapper/decdev /media/backupdisk/
offset is…
offset is…
offset is…
…
→ restored just the empty directories and some few files (that are also visible on the crashed system)

sudo cryptsetup luksClose decdev

sudo smartctl -H /dev/sda
SMART overall-health self-assessment test result: passed

photorec and testdisk don’t support btrfs for recovering files but i tried anyway. Photorec ran some hours and recovered nothing usable.
sudo photorec /dev/sda
then two options for fs
“ext2/ext3/ext4”
or
“others” ← chose this option
result:
6/10 headers found → don’t know what this means but it seems not to be complete

4

I don’t regularly use btrfs, but I would note that /dev/sda3 would probably be the btrfs volume and it should contain two subvolumes – “root” and “home” which are the subvolumes that are mounted as “/” and “/home”.

Performing actions on the main volume that probably should be done on the subvolume (filesystem) may be harmful to the file system.

5

Someone needs to inspect a complete log, i.e. one that starts from about 5 minutes prior to “Suddenly couldn’t save or edit anymore…” All of the hints of what’s going on will be in there. We can infer quite a lot from such a journal excerpt.

A file system can’t drop an entire directory on its own. Doesn’t matter the file system, it needs a very detailed and specific request for such a thing to occur.

Rule #1 in disaster is to not panic. If you panic, you’ll probably violate rule #2 which is, don’t make repairs without completely understanding the problem. Repairs are irreversible. If they go badly, they can make recovery impossible.

e2fsck on the encrypted volume tells me a superblock is invalid

You really needed to ask for help before this. That you are running commands that don’t apply to the file system you’re using is a red flag of panic. Panic leads to poor judgement. Fortunately e2fsck will fail safe on Btrfs, it has no effect. Everything else listed also are fail safe, except btrfs check --repair which should be pretty safe but can still have nasty corner cases which is why the man page says don’t use it except as a last resort which this is not. You say it is, but it’s definitely not the last resort, and also there’s no evidence there’s a file system problem - so fortunately --repair should be a noop.

And same for mke2fs -n which likewise makes no sense, seems like panic, and won’t get you valid super block locations because the command would need to be run on the plaintext virtual device which only exists after opening (unlocking) the LUKS ciphertext partition. Fortunately the use of -n avoided complete and irreversible data loss.

The kernel messages displayed show a lot of USB resets. It is possible many file system changes are in flight while this occurring, and it could lead to in-flight writes to the file system being dropped if the drive firmware doesn’t always honor flush or fua. If it honors flush or fua correctly, then Btrfs is always consistent.

Back to the original description that a directory vanished, and available free space increased, is from a file system perspective identical to a request to delete that directory, and all a file system can do is do what it’s told. I don’t have an explanation for the origin of the problem without logs though.

Snapshots any time prior to this would protect the data from user space requesting the deletion of a directory.

And an immediate shutdown following discovery of the deleted directory, while allowing only read-only mount of the file system from that point forward would prevent changes that will further commit the deletion. There is a brief moment in time on Btrfs when stale trees still exist that point to the now deleted data. But those stale trees have a high chance of being overwritten the longer the file system is mounted read-write. And a high chance of being overwritten with --repair. At that point, all recovery potential is gone.

A discussion forum is not the best location to have what amounts to an interactive discussion. I suggest asking on the Fedora matrix channel, #fedora:fedoraproject.org

6

OK yeah we need to look at this for a hint of what’s going on. But it sounds to me like the desktop got the idea to delete an entire directory, for whatever reason. If the user actually did this (whether accidentally or intentionally) it wouldn’t be logged because it’s a normal event that’s simply honored by user space all the way to the kernel.

Any sort of file system corruption is going to be noted by the kernel. Btrfs has a read time and write time tree checker that catches common problems, usually before they get written, and forces the file system read-only. It does a good job of throwing itself under the bus if there’s a Btrfs kernel bug too, and likewise going read-only before there’s permanent damage.

From the available information it sounds like a very screwy edge case bug where the user and/or the desktop got confused, and a bunch of things ended up being deleted. However spontaneous and out of no where this seems to have come - this is precisely why frequent backups are the only known way of mitigating disasters. Disasters often aren’t as obvious as hardware failure. They just as often happen exactly as described - no explanation why the files went missing.

The nice thing about Btrfs snapshots with send+receive as the backup strategy, it’s very cheap to do very frequent backups to another Btrfs disk. Replication of snapshots does not require deep traversal of either file system. If you rearrange thousands of files, Btrfs knows exactly what was moved, and the send stream simply indicates the moves - no need to resend file data, like with many other backup solutions. Therefore the incremental send replication as a backup strategy is very cheap.

It’s simple enough to do manually (which is what I do pretty regularly). But with some time investment you can automate it either with your own solution or by leveraging something like btrbk which will do all the tasks for you, whether the receive location is locally or remotely attached Btrfs.

7

A file system can’t drop an entire directory on its own. Doesn’t matter the file system, it needs a very detailed and specific request for such a thing to occur.

That’s what i mean, it happened just like that. I can not imagine how i could have triggered anything accidentally or unintentionally, as i was busy in renumbering songtracks, editing and transfering tags to filenames with only that program, since half an hour or so.

The only conspicuous was the stuttering behaviour of the tag editing program in conjunction with the audioplayer (USB), maybe system was (also) sluggish but i didn’t notice. I also remember that the last files had slashes in their album tags and i pressed a button to rename these files with that title and album tag, maybe the player or whatever process was irritated by the slashes (in that unstable condition), just a thought.

Your right, i was tense in that moment and searched concerned for a solution to rescue my data, next time i’ll be more clever, calm down and shut it down immediately. But i didn’t experiment much either, “just” did sudo mke2fs -n /dev/sda3 and e2fsck (not beeing aware btrfs is the filesystem as i always had ext4) and shut the machine down after that. Did a dd clone then. And then continued trying.

I think i will deal with doing snapshots, and probably make backups more frequently.

9

There could still be some hints in either the original or the dd clone. But anytime there are changes, it quickly wipes away all the evidence of what happened before, and makes it harder to recover.

Perhaps the best chance at this point is btrfs-find-root and try to use btrfs restore on each root in reverse (newest to oldest) order. The older the root, the more likely the trees have already been overwritten, which makes recovery impossible.

If a device doesn’t fail or do the wrong thing, best chance of recovery is a snapshot. If the device works or does the right thing, best chance of recovery is a backup. Best chance if you don’t know whether a device will fail or bad luck, is frequent replicated snapshots. It doesn’t matter what the file system is, or the backup software. The more backups (number of copies), the more frequent they are, the better the chance of recovery.

Btrfs snapshots and send/receive makes the cost of frequent replicated backups cheaper. It’s not a perfect solution, but by reducing the cost we can reduce the chance of data loss. But it still takes a commitment to do the tasks.

11

Thats interesting, but i can only mount the top volume, not subvolumes

sudo mount /dev/mapper/decdev /mnt/bdisk

sudo btrfs subvolume list /mnt/bdisk
ID 256 gen 21247 top level 5 path home
ID 257 gen 21248 top level 5 path root

sudo mount -o subvolid=256 (or …=ID256)
–>“bad usage”

sudo mount -o subvolid=256 /mnt/bdiskhome
→ “can’t find in /etc/fstab”

sudo btrfs-find-root /dev/mapper/decdev only finds one tree root and btrfs restore with that tree root only recovers the empty directories i already have. The blocks sudo btrfs-find-root -a /dev/mapper/decdev finds, are not usable with btrfs restore, that are a a lot and i tried them random.

I think i quit trying it. I found a file recovery program that promises to rescue files from btrfs, the tryout-version shows what it could recover. If it’s successful i will it share here (i’m sceptical).

Thank you for your support!

12

If you look into the /etc/fstab file on almost all fedora sustems using btrfs you will find the btrfs subvolumes are mounted with lines like this.

UUID=ee711367-4d44-479c-b30b-ec879805f29a /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=93c9125a-5d1c-45ce-bf57-55ad0b6ed5c6 /boot                   ext4    defaults        1 2
UUID=ee711367-4d44-479c-b30b-ec879805f29a /home                   btrfs   subvol=home,compress=zstd:1 0 0

Note the options used there. The UUID is the btrfs volume, the option designates the subvolume to be mounted.

A similar command to mount one of the subvolumes from the command line would read
sudo mount -t btrfs -0 subvol=home,compress-zstd:1 UUID=ee711367-4d44-479c-b30b-ec879805f29a /mnt
which would mount that subvolume at /mnt on your system. (Of course you would use your own UUID for the btrfs volume.)

This tells you the subvolumes you are working with and can probably be accessed at /mnt/bdisk/home and /mnt/bdisk/root.

13

Elaborate?

A subvolume mounted via -o subvol/subvolid is merely a bind mount behind the scenes. There’s no trouble with the top-level (ID 5 a.k.a. ID 0) subvolume or any other subvolume being mounted multiple times and variably modified via any mount point.

14

Command requires device node and mount point, same as the subvol mount option.

15

Finally i did a fresh install and will restore my two month old backup. Anyway i tried your suggestions with gparted-live-system on my fresh install.

My /etc/fstab:

#UNFIGURED FSTAB FOR BASE SYSTEM
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0

As i was on live-system (USB) it’s its fstab… when i look into /mnt/bdisk/root/etc/fstab i see correct UUIDs and the command you provided to mount works.

yes, works nice on my new system.

True, tested it with my newly set up system and it works.
sudo mount -o subvolid=256 /dev/mapper/decdev /mnt
Tried it before but not with the block device.

Also, i found this to be a good starting point when working with subvolumes