Please find attached screenshot. From few threads I tried fsck.mode=forced as well but that didn’t help.
That second image shows a file system error on the btrfs file system. One would need to do a repair while booted from live media since it appears the default fix during boot is not up to the task.
1 Like
Any guide for repair from live media?
Booting from the Installation Media (not the Live Image) does have a rescue option to recover a damaged Fedora installation, it may help you recover. The errors do indicate the filesystem is in need of repair, at least a scan. If this is a fresh install I would try re-installing as the fastest solution. Or using the live media, try to mount and repair the errors with btrfs tools.
Okay. This is not fresh install but desktop home use. I will try mount with live usb then see if it can mount drive or not.
Guys Thanks,
‘sudo btrfs check --repair device’ did the trick 
Okay still problem folders have permission issues and after reboot getting same problem as before.
What tells you that?
If it appears it may be due to SELinux then it may be worthwhile to check (and even repair) the context labeling with sudo restorecon -v -n -R / to relabel everything, or one can even just start at the part of the directory tree that seems problematic. The -n tells it to only report what it will change and removing the -n will actually make the changes.
does this happen after trying to update the kernel? i ask this because it happened to be a few days ago and i had to delete the latest version of kernel and reupdate the system
I solved it by backing up data via liveUSB and reinstalling Fedora.
Sorry I’m slow responding. I think this is the result of a tree log bug (I’m not remembering if it’s a write time or read time bug). Anyway you want to upgrade to current stable 6.4 or 6.5 series kernel.
It is possible to safely work around the problem mount -o ro,rescue=nologreplay and get your data out. Very slightly more risky, and may involve losing up to 1 minute of writes at the time the problem (crash, power fail, reboot) is to run sudo btrfs rescue zero-log /dev/ on the partition containing the Btrfs file system. At next boot, log replay won’t be attempted, so it won’t run into the problem. The file system itself is OK.
Note that zero-log command is only appropriate when encountering the kernel message saying log replay failed, e.g.
[3.040269] BTRFS: error (device sda3: state EA) in btrfs_replay_log:2322: errno=-17 Object already exists (Failed to recover log tree)
It isn’t a proper fix for everything or even most things, it’s just for this specific complaint when mounting the file system fails.