Fix a Btrfs Read-Only File System Error on SUSE Linux Enterprise

You try to save a file or update a service on SUSE Linux Enterprise Server (SLES), and Linux responds with “Read-only file system.” That message can mean the mount was deliberately set read-only, you booted into a read-only Snapper snapshot, or Btrfs detected a problem and stopped accepting writes to protect the volume. These causes need different responses. Start by identifying which filesystem and mount are involved; do not force a remount or run a repair command before checking the kernel logs and protecting important data.

What the error means

Btrfs is a copy-on-write Linux filesystem used by default for the SLES root filesystem in many standard installations. A Btrfs subvolume is an independently mountable part of a filesystem; a snapshot is a point-in-time copy of a subvolume that shares unchanged data blocks. Snapper and the SLES boot menu can use snapshots to recover from system changes. Booting a snapshot intentionally mounts the included parts read-only. Separately, Btrfs can switch to read-only mode after detecting certain structural errors to avoid further writes. SUSE documents snapshot behavior in its SLES 15 SP7 Snapper guide; the Btrfs project explains that filesystem structural checks can switch a volume to read-only mode to prevent further damage in its tree-checker documentation. Your exact menu labels and available recovery options can vary by SLES service pack and storage layout.

A permissions problem is different. “Permission denied” usually points to ownership or access controls; “Read-only file system” (often shown as EROFS) points to the filesystem or subvolume state. Changing file permissions with chmod will not make a read-only mount writable.

Before you change anything

If this is a production server, a database volume, or the only copy of important data, contact the system administrator and confirm the backup before attempting recovery. When the system is still readable, copy the most important files to separate healthy storage if you can do so without stressing a failing device. Btrfs may have recent metadata changes only in memory after a critical error; an unmount or reboot can lose those uncommitted changes. If logs mention I/O errors, disappearing devices, or repeated resets, prioritize storage health and data protection over restoring writes.

Do not run btrfs check --repair as a routine first step. The Btrfs project warns that repair mode can cause damage and cannot fix every kind of corruption. Do not repeatedly force a read-write remount either: it may fail immediately when the kernel has protected the filesystem for a reason.

Step 1: Identify the affected mount

Use the path where the write failed. For example, if a service cannot write to /srv/app, inspect that path rather than assuming the root filesystem is the problem:

findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS

Replace /srv/app with the affected file or directory. Check the output for the Btrfs source, the mount target, and an option of ro or rw. The target may be /, a separate data mount, or a subvolume. Record the source and target before continuing. If the command reports another filesystem type, Btrfs-specific steps do not apply to that path.

Check the kernel messages from the current boot for the reason the filesystem became read-only:

sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'

Look for Btrfs error or “forced readonly” messages, checksum or tree errors, device I/O failures, and device disconnects. A log line is a clue, not a complete diagnosis. Save the relevant messages and timestamps before rebooting, because logs can be useful to the storage or hardware support team.

Step 2: Check for an intentional read-only snapshot

If the server was started from a bootable snapshot in GRUB, files included in that snapshot are read-only by design. This is a recovery environment for checking a previous system state; it is not automatically the permanent restored system. Confirm the boot entry with the administrator, then reboot and select the normal default SLES entry if the snapshot boot was accidental. SUSE documents that booting a snapshot mounts its included filesystem parts read-only and describes the separate rollback procedure in its SLES 15 SP7 Snapper recovery guide.

A particular snapshot may also be read-only even while the parent filesystem is mounted read-write. If you are intentionally working with a snapshot, inspect it without changing it:

sudo btrfs property get -t subvol /path/to/subvolume ro

Replace the path with the subvolume’s mount path. A result of ro=true confirms that the subvolume property is read-only; the Btrfs property reference documents this flag. Do not simply flip a Snapper-managed or received backup snapshot to read-write: read-only status can be part of rollback or incremental backup assumptions. Use a supported Snapper workflow or create a separate writable subvolume when that is the intended task.

Step 3: Review mount configuration and storage status

If findmnt reports ro and the logs show no Btrfs or I/O error, inspect the matching mount entry in /etc/fstab. A mount may have been deliberately configured read-only for recovery, an appliance image, or a data-protection policy. Change configuration only after confirming the intended state with the service owner. Also check whether the system uses a transactional or read-only-root deployment: SLES documents such configurations and their maintenance workflow in its transactional updates guide. If the entry is explicitly meant to be writable, the device is healthy, and the path is not a read-only snapshot, an administrator can attempt a temporary remount:

sudo mount -o remount,rw /mountpoint

Replace /mountpoint with the exact target shown by findmnt. This does not diagnose or repair corruption. If it fails, returns an error, or the kernel logs show storage problems, stop and move to recovery planning rather than retrying with more options.

For a possible capacity issue, review Btrfs allocation and device status:

sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint

SUSE notes that ordinary disk-free summaries can be misleading on Btrfs because data and metadata are allocated separately. Snapper snapshots can also retain substantial space. However, “No space left on device” is not identical to a Btrfs read-only error; identify which message the application actually received. Do not delete snapshots just to test a theory. Confirm what they contain and follow the applicable retention policy first. See the SLES 15 SP7 file system troubleshooting guide.

Step 4: Decide whether the filesystem needs recovery

If Btrfs errors appear in the kernel log, the device is missing, or a remount is refused, preserve logs and arrange a verified backup or storage-level snapshot before repair work. For a non-root data volume, plan a maintenance window and unmount it before offline checks. For the root filesystem, use SUSE installation or rescue media and follow the procedure for the exact SLES release and error signature. Do not guess a device name: a Btrfs filesystem can span multiple devices, so first establish all members and the correct mount or device identifiers.

SUSE’s SLES 15 SP7 administration guide has a specific section for a root Btrfs partition that cannot be mounted. It discusses recovery options for that boot failure. Those instructions do not mean every mounted read-only filesystem should have its log cleared. The upstream btrfs-rescue manual explains that btrfs rescue zero-log is for certain log-replay failures during mount and can discard changes since the last committed transaction. Use it only when the recorded error matches the documented case and the recovery plan accounts for possible data loss.

btrfs check runs read-only by default on an unmounted filesystem. Keep it that way for initial assessment and share its output with SUSE support or a Btrfs specialist. The upstream btrfs-check manual explicitly cautions against using --repair without advice from an experienced user or developer. Never run an offline checker on a mounted, changing filesystem.

Step 5: Verify recovery

After the cause has been corrected, reboot only when the recovery plan calls for it. Then use findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONS again and confirm the intended mount is read-write. Check the kernel log for fresh Btrfs or I/O errors. Finally, verify the affected service or application can perform its normal operation, and confirm the backup remains available. A successful remount alone does not prove that the storage is healthy.

If the filesystem returns to read-only mode, the device drops out, or errors continue, stop writes and escalate with the saved logs, findmnt output, Btrfs device list, SLES service-pack level, and storage-controller details. That evidence helps distinguish an intentional snapshot or mount option from media, connection, driver, or filesystem damage—and avoids turning a protective read-only state into a larger recovery problem.