My ubuntu 18.04 boots into read only filesystem / and i really dont know why. I know, that a bad fstab can cause this problem, but my fstab looks okay:

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
#UUID=ec9192f0-a26a-4e52-be83-084fd6599e55 /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0
#/dev/sdb1 /home/nextcloud-storage ntfs-3g utf8,dmask=007,fmask=007,umask=007,uid=www-data,gid=www-data,noatime 0

I already #comment my /dev/sdb1 to check this. Also weird, maybe it has something to do with this problem: When i uncomment the /dev/sdb1 line, my /dev/sdb1 will be mounted correctly into /home/nextcloud-storage (still readonly file system /), lsblk show this but blkid shows only my /dev/sda1 with the UUID - not /dev/sdb1.

I can use of course sudo mount -o remount,rw /dev/sda1 / to get right access, but this won't fix my problem.

Has anyone an idea how to get rid of this?

  • 1
    Why is / commented out? Does it mount as read/write if you uncomment it and remove errors=remount-ro from the line? Jul 12, 2020 at 17:37
  • 1
    Stupid me. I really dont know with this is commented out. Sure, this was the problem. Shame on me. But thanks anyway! Jul 12, 2020 at 17:43

1 Answer 1


Uncommenting the line, as already mentioned, would surely solve the problem (and, as you confirmed, it actually did).

As this might be someone else's problem, and the title says fstab is alright, I'll add something else that I think might be relevant for people looking for the same question. I'm uncertain whether the errors=remount-ro is a standard on your distribution or not, but it might be related to how errors are handled by your "init" scripts. It's often the case that when system starts as ready only there was an error, like a filesystem error, that needs to be fixed, but different distributions might handle that by different means. But regardless of how it's handled, tools like e2fsck cannot run safely on a read-write mounted filesystem, and that's why system sometimes might fallback to read-only.

If anything like this happens, running an e2fsck might solve a filesystem issue (but beware it might result in data loss). The man pages for e2fsck contain instructions on how to proceed and the implications of each option.

Also, running a dmesg command might show you why the root ended up mounted as read-only, in the case of some hardware error.

Not the answer you're looking for? Browse other questions tagged .