Read-only file system means the mounted filesystem will not accept writes at that path. It differs from Permission denied: changing file ownership or adding sudo cannot make a read-only mount writable.
Identify the exact mount
findmnt -T /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /path/that/failedReplace the example path with the directory where the write failed. Record the mount target, device, filesystem type and whether the options contain ro. A path in a container, live image, snapshot or recovery environment may be intentionally read-only.
Look for filesystem or device errors
journalctl -k -b | grep -i -E 'read-only|I/O error|filesystem|ext4|xfs|btrfs'
dmesg --level=err,warnLinux may remount a filesystem read-only after detecting serious errors. Repeated I/O errors can indicate failing storage or a connection problem. Preserve important data and investigate hardware before forcing more writes.
Remount only when the filesystem is healthy
If the mount was intentionally created read-only and you have confirmed that it should be writable, use the exact target reported by findmnt:
sudo mount -o remount,rw /exact/mount/targetThen repeat findmnt and test a controlled write. If remounting fails or the kernel immediately returns it to read-only, stop and inspect the logs.
Repair an ext filesystem offline
Filesystem repair must match the filesystem type and usually must run while it is unmounted. For an ext2/3/4 data filesystem, a maintenance-session example is:
sudo umount /exact/mount/target
sudo fsck -f /dev/exact-deviceDo not guess the device name, and do not unmount the active root filesystem from the running system. Boot recovery or external media when the root filesystem needs offline repair. XFS and Btrfs use their own tools and procedures.
Rule out nearby errors
If the mount is writable, use the permission diagnostic guide. If writes fail because capacity or inodes are exhausted, follow the no-space checklist and df and du guide.
Sources and verification
Mount behavior and remount syntax checked against the Ubuntu mount manual on September 11, 2026. Offline repair was not run against the publishing host; always use the tool for the identified filesystem.
