restorecon -R /path/to/drive/mount when my system crashed and rebooted due to a different issue.
Now, when I try to mount the drive with
mount -a, it hangs and checking
journalctl -xe shows that the device’s start service failed and timed out.
btrfs check on the device works fine and reports no errors.
SMART reports no errors either. Just a healthy new drive.
I imagine this is an issue with SystemD/SELinux due to the incident before this issue occurred, but I am uncertain of how to fix the drive if I cannot mount it to do context operations on it.
For reference, I had upgraded from Fedora 30 to Fedora 31, and found I couldn’t access my files over SMB share as I could before. Just the directories. I did
restorecon -R /path/to/drive/mount and this resolved my issue as I could now access the files.
However, upon a normal reboot, I lost access again, and ran the command again, and that fixed it once more. That’s why I was running
restorecon, as I had just rebooted once more.
Anyway, here is the Journal Control showing the timeout error:
I can’t get the hung
mount command to stop, even with
kill -s 9 <pid>, but I’m more concerned about why this is happening at all.
When I try to
mount, the drive goes up to 99% usage, then drops back to 0% after a minute or two, presumably when the timeout limit is hit.
Does anyone have any idea why this might be happening?
journalctl -f showing after disabling SELinux entirely with
vi /etc/sysconfig/selinux to
Edit 2: Googling has resolved me to these two stackexchange questions that revolved around
finding a device by that UUID.
However, when I do
blkid, it matches the
UUID in the
/etc/fstab. And more importantly, I’m trying to mount the device with this command:
mount -t btrfs /dev/sdb /path/to/drive/mount
So UUID’s shouldn’t be an issue. Targeting
btrfs check works fine. Same with
So I’m not understanding why it might not be finding the UUID, unless SystemD is somehow hiding it from itself.