I was 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.
Doing 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?
Edit: journalctl -f
showing after disabling SELinux entirely with vi /etc/sysconfig/selinux
to disabled
.
Edit 2: Googling has resolved me to these two stackexchange questions that revolved around /etc/fstab
and 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 /dev/sdb
with btrfs check
works fine. Same with smartctl
, fdisk
, etc.
So I’m not understanding why it might not be finding the UUID, unless SystemD is somehow hiding it from itself.