My home directory on Fedora 25 is suddenly read only

Operating Systems & Open Source Linux
1

My system is using BtrFS. Main OS disk is partitioned like so:

Disk /dev/sdd: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xeebf978b

Device     Boot    Start       End   Sectors   Size Id Type
/dev/sdd1  *        2048   2099199   2097152     1G 83 Linux
/dev/sdd2        2099200  18710527  16611328   7.9G 82 Linux swap / Solaris
/dev/sdd3       18710528 500117503 481406976 229.6G 83 Linux

Boot is of course sdd1. Swap is sdd2. And my root OS is on sdd3.

I've created a BtrFS subvolume for my home directory (to separate root snapshots from home snapshots since home tends to be large and inconsequential). So my mounts look like so:

/dev/sdd3 on / type btrfs (ro,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root00)
/dev/sdd3 on /home type btrfs (ro,relatime,seclabel,ssd,space_cache,subvolid=258,subvol=/home00)
/dev/sdd1 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sdd3 on /home/user/QEMU type btrfs (ro,relatime,seclabel,ssd,space_cache,subvolid=259,subvol=/home_QEMU)
/dev/sdb on /mnt/seagate type btrfs (rw,relatime,seclabel,space_cache,subvolid=2252,subvol=/seagate)
/dev/sdc on /mnt/WD type btrfs (rw,relatime,seclabel,space_cache,subvolid=2256,subvol=/WD)

QEMU is another subvolume for VM images, configs, and such.

I've tried fsck and btrfs check, but neither report an issue.

Rebooting temporarily fixes it until it happens again.

2

Not familiar with BTRFS, but mounting doesn't mounting /home with the "ro" flag cause it to be read only not read/write?

3

Check if the UUID of the btrfs partition is the same as in /etc/fstab. If not, rewrite fstab.
If it matches, the partition is broken.

Even with btrfs it's best practise to keep /home on a separate partition, so in the case of a fs break it's easiest to just reinstall /

4

You are right. It somehow got remounted with RO.

After rebooting, checking with sudo mount gives that it has the RW flag instead.

What would remount it with RO during regular use? Strange....

Hmmm. Here is /etc/fstab:

UUID=3798af0c-1cec-4acd-ab6a-2a1df3819b45	/                       btrfs   subvol=root00   0	0
UUID=db612565-4e42-4420-9e52-dfdefdf8721f	/boot                   ext4    defaults        1	2
UUID=3798af0c-1cec-4acd-ab6a-2a1df3819b45	/home                   btrfs   subvol=home00   0	0
UUID=3798af0c-1cec-4acd-ab6a-2a1df3819b45	/home/user/QEMU     btrfs   subvol=home_QEMU 0	0

Here is results of sudo btrfs sub list -u /home:

ID 257 gen 24455 top level 5 uuid 7fb65a63-9d5e-b44c-9dfc-791d235e11ca path root00
ID 258 gen 24455 top level 5 uuid 320acf8f-7e52-f04c-806f-7490a2fa24ae path home00
ID 259 gen 24111 top level 5 uuid 6b0e2c52-e446-764c-b264-52ad45a3c854 path home_QEMU

So they're not the same, but I believe the UUID for the subvolumes is separate from the UUID for the partition itself. So, in the /etc/fstab, it points at the partition UUID, while the subvolume=home00 is pointing to the subvolume.

Output of ls /dev/disk/by-uuid:

lrwxrwxrwx. 1 root root  10 Feb 14 04:42 1e10d540-ef7b-460d-a566-7ceb53591f22 -> ../../sdd2
lrwxrwxrwx. 1 root root  10 Feb 14 04:42 3798af0c-1cec-4acd-ab6a-2a1df3819b45 -> ../../sdd3
lrwxrwxrwx. 1 root root   9 Feb 14 04:42 911096d6-14cf-4d45-a9b4-6803ce22f044 -> ../../sdc
lrwxrwxrwx. 1 root root   9 Feb 14 03:17 a404a162-0ad4-4a25-87a5-7005768ab23a -> ../../sdb
lrwxrwxrwx. 1 root root  10 Feb 14 03:17 C6FA2DADFA2D9AA7 -> ../../sda2
lrwxrwxrwx. 1 root root  10 Feb 14 04:42 db612565-4e42-4420-9e52-dfdefdf8721f -> ../../sdd1

So yeah. It's using the partition UUID and not the subvolume UUID.

5

That being stated, hey, all! Want to coexist with y'all.