Record the affected path, time and application errors. Confirm the actual mount and whether it is intentionally read-only. Ensure backup or rescue access is available and avoid unnecessary writes on a potentially failing device.

1. Inspect findmnt -T PATH and current mount options. Check kernel logs for filesystem, block-device, controller or I/O errors around the transition.
2. Determine whether the cause is an intentional mount policy, a degraded device, lost network storage, a full backend or filesystem corruption. These require different recovery paths.
3. Stop applications that are repeatedly failing writes, using their supported shutdown procedure where possible. Preserve readable critical data to separate healthy storage if the situation warrants it.
4. Arrange an offline or rescue maintenance window for filesystem checking when required. Use the correct tool for the actual filesystem and its documented mount-state requirements.
5. Repair underlying hardware or storage connectivity before returning the filesystem to normal service. Restore from backup when the filesystem cannot be repaired reliably.

Use the server console or an existing administrative session. Replace /var with the affected path. These checks inspect the mount and recent kernel warnings without attempting to remount, repair or write to the damaged filesystem.

findmnt -no SOURCE,FSTYPE,OPTIONS --target /var
sudo journalctl -k -b -p warning --no-pager -n 80

Read the result: An ro option confirms the current mount is read-only. Correlate the time of the change with I/O errors, filesystem errors, virtual-disk events or storage disconnections. A read-only root filesystem can also prevent ordinary application logs from being written, making kernel evidence particularly useful.

Preserve the output outside the failing volume when possible. Filesystem repair depends on its type and usually needs an appropriate offline state. Repeatedly forcing a read-write remount can worsen an unresolved storage problem and is not part of this diagnostic example.

Only after the cause is understood and the filesystem is safe to use. A forced remount is not a repair for corruption, an unavailable backend or failing hardware.

After a controlled recovery, confirm mount options, kernel logs and device health are stable. Test a small authorized write and application integrity, then observe the storage under normal workload. Recheck backup success because recent failures may have affected recovery coverage.

Do not run a repair utility against a mounted writable filesystem or use an ext-family checker on XFS. Avoid repeatedly rebooting a failing disk. If the error indicates hardware failure, prioritize preserving data and replacing the faulty storage rather than only clearing a filesystem flag.

• Inspecting an unbootable Linux server from rescue mode
• Recovering service when a Linux filesystem is full
• Testing a Linux server restore before an emergency
• Reading logs from the previous Linux boot

• Debian manual: Findmnt.8.en
• Debian manual: E2fsck.8.en
• Debian manual: Xfs Repair.8.en

• systemd journalctl manual, published by Debian