btrfs rootfs mounted readonly


I’m having issues with the rootfs being mounted as readonly by default. This has been an issue since I installed openSUSE 15.2. It was ok for the first few weeks, but since then it’s always been readonly by default (which prevents automatic updates from working etc).

/dev/sda2 on / type btrfs (**ro**,relatime,ssd,space_cache,subvolid=256,subvol=/@)

I don’t see any error messages (in dmesg). And I can remount the partition as rw just fine manually (mount -o remount,rw / ). The file system is btrfs - and I’m still running 15.2.

I did try the obvious fix by running a file system check (btrfs check --repair) using a rescue system. But no issues are reported, nor does the checker attempt to fix anything.

Any pointers what could cause this or where to look into would be greatly appreciated.


Out of space maybe???

No, it has lots of free space left. And after I remount with “rw” then installing new SW and all updates are working fine…

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2       62918656 19591732  42704236  32% /

BTRFS file system???

If so maybe hidden snapper directories full??

Worth checking even if probably ok with 62 gig root. Use btrfs commands (man btrfs) to get used space since normal space programs will not show snapshots

Probably need to look at logs to see why RO mount

Provide full ouptut of “journalctl -b” after boot. Upload to Also show output of “lsinitrd /boot/initrd etc/cmdline.d/95root-dev.conf”

I did try the obvious fix by running a file system check (btrfs check --repair)

There is nothing obvious here. It is not a check, it is rather dangerous operation which should be invoked only on direct recommendation of btrfs developers.

Due the way rootfs is mounted I’d say snapshots aren’t enabled on this system. Not sure but I think they can de disabled during install.

As pointed out by arvidjaar you jumped at the gun here. Since you can simply remount it read/write afterwards I’d say there’s no structural damage to be repaired. Something is mounting the system R-O, you’ll need to provide full logs to further troubleshoot.

Ok, ok, I’ll leave the “–repair” option alone. Indeed it does say so in the man page to be careful… Hopefully it hasn’t done anything. It’s log output suggested it hadn’t found any errors.

Before I diving into further details - I made some tests with “yast partitioner”: I toggled the root device to be mounted readonly (and planned to toggle the property again later). Yast allows to me to make selections for the root device in the GUI - but it doesn’t change anything in /etc/fstab. Indeed yast actually says “nothing changed” when applying the property changes to the root partition - which is clearly not right (since I did change a root device’s mount property). Changing properties does work as expected for all other partitions.

I then noticed that yast does not write any entry for the root device to /etc/fstab.

Maybe that’s a stupid question - but shouldn’t there be an entry for the “/” in fstab?

Here’s what “yast partitioner” wrote to fstab:

/dev/sda2                                  /var                    btrfs  subvol=/@/var        0  0
/dev/sda2                                  /usr/local              btrfs  subvol=/@/usr/local  0  0
/dev/sda2                                  /tmp                    btrfs  subvol=/@/tmp        0  0
/dev/sda2                                  /srv                    btrfs  subvol=/@/srv        0  0
/dev/sda2                                  /root                   btrfs  subvol=/@/root       0  0
/dev/sda2                                  /opt                    btrfs  subvol=/@/opt        0  0
UUID=7381128a-1649-4b2c-9d7d-e5f3dc65ddf0  /home                   ext4   data=ordered         0  2
/dev/sda2                                  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
/dev/sda2                                  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=C54A-B352                             /boot/efi               vfat   defaults                     0  2
UUID=27f3e4b6-e896-4c2c-bcdf-92500314a480  /mnt/data               ext4   user                  0  0
UUID=ffbe0cd8-5bf8-4409-960a-b60c10ae38e9  /mnt/videos             ext4   user                  0  0
UUID=8cb08b30-81ed-44ed-a0d0-0c7232b8f8bb  /mnt/music              ext4   user                  0  0
synology:/volume1/music                    /synology/music         nfs    user                  0  0
synology:/volume1/photos                   /synology/photos        nfs    user                  0  0
synology:/volume1/video                    /synology/video         nfs    user                  0  0
synology:/volume2/data                     /synology/data          nfs    user                  0  0
synology:/volume2/backup                   /synology/backup        nfs    user                  0  0

I went ahead and manually added an entry for “/” to fstab:

/dev/sda2                                  /                    btrfs  subvol=/@        0  1

That did help. Now the root directory is mounted as readwrite when booting - as expected.
But now “yast partitioner” is unhappy: it complains the root device was shadowed by another partition - and I can no longer manager any of the partitions through the GUI.

Am I completely heading into the wrong direction here - or is the missing entry in fstab triggering the readonly issue?


To me it looks that the root file system was mounted ro during boot (as normal), but at the moment it should remount rw, there was no fstab entry to fill in the details. So it stayed ro.

Now the big question is of course why there is no entry for / (any more).

It might be that we never will know when it was deleted (but you seem to have some time stamp for it: “after the first few weeks” :().

Now you created one out of hand. The fact that you now have another problem may point to an error in that hand made entry. As I do not use Btrfs, I can not comment but hope others can.

Ok, thanks everyone. I think I’ve got it sorted now…

I changed the missing fstab entry to:

/dev/sda2          /                       btrfs  noatime,ssd,space_cache       0  1

and now everything seems to work as expected: the root directory is rw mounted when booting. And yast also accepts it - and is able to apply changes again.
Yast didn’t work when mentioning the “subvol=/@” in the root directory’s fstab entry (even though this still shows up when checking the status of actually mounted partitions later):

user@machine:~> mount|grep sda2
/dev/sda2 on / type btrfs (rw,noatime,ssd,space_cache,subvolid=256,**subvol=/@**)

Adding the “subvol=/@” to fstab would work fine when booting. But this would cause yast to fail with some “partition is shadowed” error message.

So, I guess it all boils down to some weirdness with “yast partitioner”. Initially my issue obviously started when somehow the root entry got lost. And while this entry is missing in fstab, then yast happily and silently just ignores any property changes made to this partition in the GUI.

Hope all is well again now.


subvol=/@ is not the default rootfs in a new install (I’m not sure if that’s the case if snapshots are disabled).

Omitting the subvol flag you get the real default subvolume, you can see which one:

btrfs subvolume get-default /

Nonetheless keep subvol= out of the rootfs entry. Keep noatime but other flags can be omitted as well since they are the defaults already.