How to Fix "chown: changing ownership of: Read-only file system"

chown refuses to change file ownership because the filesystem itself is mounted read-only — no amount of sudo or permission tweaking will get around this, since the block device isn't accepting writes of any kind at the moment.

The Problem

Running chown, even as root, fails with a filesystem-level error rather than a permissions one:

$ sudo chown www-data:www-data /var/www/app/uploads
chown: changing ownership of '/var/www/app/uploads': Read-only file system

Trying to write a file directly confirms the deeper issue — it's not specific to chown at all:

$ touch /var/www/app/test.txt
touch: cannot touch '/var/www/app/test.txt': Read-only file system

Why It Happens

A filesystem mounted read-only rejects every write operation at the kernel level, regardless of user permissions or root privileges — chown, chmod, touch, and any other write attempt all fail identically. This happens for a specific set of reasons:

• Intentional read-only mount — some systems (containers, live USB environments, certain cloud images, hardened production servers) deliberately mount root or specific partitions as read-only for security or immutability.
• Filesystem corruption or a detected error — the kernel automatically remounts a filesystem read-only when it detects corruption, as a protective measure against making the damage worse with further writes.
• A failing or disconnecting disk — hardware issues, a failing SSD, or a flaky USB/network-attached drive can trigger the kernel to fall back to read-only mode.
• Docker overlay or bind-mount configuration — a container volume mounted explicitly as read-only (:ro in a Docker run command or Compose file) behaves exactly this way from inside the container, by design.
• Disk quota or full disk conditions on certain filesystem types can sometimes trigger a defensive read-only remount as well.

The Fix

First, confirm whether the filesystem is actually mounted read-only:

mount | grep " / "

/dev/sda1 on / type ext4 (ro,relatime)

The ro flag confirms it. If this was intentional and you need to write temporarily, remount it read-write:

sudo mount -o remount,rw /

For a different mount point than root, target it explicitly:

sudo mount -o remount,rw /var/www

If the remount command itself fails or the filesystem immediately reverts to read-only, that's a strong signal of underlying corruption or hardware failure rather than an intentional configuration — check the kernel log for the actual reason it went read-only in the first place:

dmesg | grep -i "read-only\|error\|ext4" | tail -20

[12045.291823] EXT4-fs error (device sda1): ext4_journal_check_start:83: Detected aborted journal
[12045.291840] EXT4-fs (sda1): Remounting filesystem read-only

This confirms the kernel remounted it defensively due to a detected filesystem error. In that case, don't just force it back to read-write and keep working — unmount it properly (from a live environment or single-user mode if it's the root filesystem) and run a filesystem check first:

sudo umount /dev/sda1
sudo fsck -y /dev/sda1

Only remount and resume normal use after fsck completes and reports the filesystem clean, since continuing to write to a corrupted filesystem risks losing more data.

Still Not Working?

If you're inside a Docker container and getting this error, check whether the volume or bind mount was explicitly configured as read-only in your run command or Compose file — this is expected behavior, not a bug, and the fix is in your container configuration rather than the filesystem itself:

docker inspect <container_id> | grep -A 3 "Mounts"

If you see "RW": false for the relevant mount, update your Compose file or run command to drop the :ro suffix if write access is actually needed:

# docker-compose.yml
volumes:
  - ./uploads:/var/www/app/uploads:rw

If the remount succeeds and fsck reports no errors but the disk keeps reverting to read-only over time, treat it as a sign of failing hardware — back up your data immediately and plan to replace the disk, since a filesystem that repeatedly self-protects this way is usually telling you the underlying storage is unreliable.