Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article6 min readViews0

File system became read-only: diagnostics in Ubuntu 24.04

Determine the mount mode for the application directory and search for preceding kernel messages. The commands do not remount partitions or repair the file system; the result helps select the next recovery procedure.

АльбинаCommunity author★ 127
Comments 0

External drive in a metal case next to a protective sleeve. Generated illustration.
In this article

The error Read-only file system indicates that the write operation hit a limit imposed by the available filesystem or mount. Granting additional user permissions is not guaranteed to help. First, determine which mount serves the problematic path and why writing is blocked. Do not start by attempting to forcibly restore write mode.

This guide is designed for Ubuntu 24.04 LTS, findmnt from util-linux 2.39.3, and journalctl from systemd 255. Documentation and syntax were verified on September 26, 2026. Read commands were executed in an isolated Ubuntu 24.04.3 environment; a container filesystem is available there, but no kernel log exists. Forcing a real disk into read-only mode as a failover was not reproduced, recovery was not tested, and is not offered here.

Distinguish between write prohibition and lack of permissions

Save the exact application error text, timestamp, operation, and full directory path. The message Permission denied indicates a different class of restrictions and requires verification of the owner, permissions, and protective mechanisms. The message No space left on device leads to checking the location and inode. These signs may appear in a single incident, but substituting one diagnosis for another based on the general phrase "file cannot be saved" is not allowed.

If the application shows only a general message, first find the root cause in its log. Do not create test files in the database directory or change permissions for experimentation. Further reading of the state does not require writing to the problematic directory.

Find the mode specifically for the required path

For an existing directory /var, the command looks like this:

findmnt --target /var --output TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS

Replace /var with an existing directory where the application cannot write data. If the name contains spaces, enclose the entire path in quotes. Checking the server root instead of the application directory may show a different mount and lead to an incorrect conclusion.

The --target parameter selects the file system serving the specified path. The explicitly set --output retains the required columns: TARGET for the mount point, SOURCE for the source, and FSTYPE for the type. VFS-OPTIONS displays mount-level parameters, while FS-OPTIONS shows file system parameters. This separation is useful when one data view is more restricted than the other.

Look for a separate value of ro or rw among the parameters. ro denotes read-only mode, while rw indicates read-write mode at the corresponding level. If the mount has ro, the presence of rw in the underlying file system does not make the path writable. Conversely, seeing a single rw does not prove that an application can write: permissions, security restrictions, and storage specifics remain.

The ext4 parameters may contain errors=remount-ro. This is an error response policy, not proof that the transition has already occurred. The current mode and event messages must be checked separately. Do not simply search for the substring ro in the entire output: it may be part of another parameter.

Consider the environment from which you are viewing

The command shows mounts in the namespace of the current process. If the store runs in a container, the output on the host may differ from what is available inside the container. Diagnostics must be performed by an administrator in the correct environment with authorized access; guessing the application's result based on a neighboring container is not allowed.

In our local execution, the command showed type overlay and mode rw at both levels. This confirms syntax parsing and column output in this environment, but tells nothing about the reader's disk. The source could also be network storage. In that case, part of the cause lies on the storage server side and is not visible from the store's virtual machine.

For a typical user, viewing mount points is often sufficient. An access error or missing path is a reason to check the launch context and path, not to automatically elevate permissions for all files. If the output is empty, do not treat this as proof of correctness: first ensure the command executed successfully and that the specified directory exists in this environment.

Review messages up to the point of failure

If a system log is available, read the kernel messages from the current boot session for the last 30 minutes:

journalctl --dmesg --boot --since "-30min" --no-pager

Reading the system log may require administrator rights or membership in an authorized group. Use the access already provided; do not change groups or logging settings for this instruction. In a container, the host log is often unavailable regardless of whether the program journalctl is present.

--dmesg limits the message selection to kernel messages, --boot to the current load, and --since sets the interval start. --no-pager outputs the result without an interactive viewer. If the failure occurred earlier, meaningfully expand the interval: an excessively large query may read too much data and create additional load on the storage.

Look for input/output error messages, file system issues, and transitions to read-only mode. Match them with the source from findmnt and the application error time. A single line about a different device does not explain the failure of the required directory. Do not limit the search to a single word: messages differ across file systems and drivers.

In a local check, the command completed without entries and reported no log files. This is a limitation of observation, not proof of the absence of errors. Similarly, after a reboot, the current boot session may no longer contain failure events. Accessible history or host administrator records will be needed if they have been preserved.

Where to stop

If read-only mode is confirmed and storage errors occurred nearby in time, further actions depend on the file system type, media condition, and available backups. Do not run repairs on a mounted production database, do not substitute a random device, and do not remount it to read-write just to make the message disappear. First, a plan for data preservation and recovery specific to the architecture is required.

Provide the responsible specialist with the exact path, timestamp, mount type and source, individual VFS and filesystem parameters, and relevant incident log lines. Exclude secrets and customer data. This package allows distinguishing between an intentionally unmounted volume, a container limit, and a storage failure response—three situations requiring different follow-up actions.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.