If any fstab mount points are missing, I think you run into this error.
I’m not familiar with snapper so I don’t know if it’s modifying /etc/fstab or if the clean up could have deleted the subvolume assigned to the /home mountpoint.
You could use a Live USB stick to recover. I suggest using -o ro,nodiscards mount option to limit the changes to the file system.
Another option you can modify+add boot parameters:
systemd.volatile=overlay fstab=no and the existing rootflags=subvol=root should become rootflags=subvol=root,nodiscards
This provides a LiveOS-like environment, all writes are directed to memory, they’re not persistent.
Note, since fstab is ignored, your /home definitely will be empty. That doesn’t necessarily mean there’s data loss. You’ll need to dig through the list of subvolumes and piece together what remains.
I kinda like the USB stick approach because you can definitely avoid any further writes to the file system as a whole. And that improves the possibility the btrees for deleted subvolumes/snapshots are still present and can be recovered.
Thing is, if this is an SSD, any deleted data and metadata is soon subject to discards and the SSD itself will erase those btrees and data. If discards have already been issued, the recovery options are probably limited to independent backups.
And that leads to the “a snapshot is not a backup” observation. And also leads to thinking about Btrfs snapshots differently, for example in terms of using them for cheap replication to another Btrfs file system either locally or remotely. This is a form of backup, because of the replication to an independent file system, ostensibly on another device.
Automating this is the function of btrbk which is in Fedora repo. It’s different from snapper. It does manage it’s own snapshots as well as the replication policy.
