Файловая система стала доступна только для чтения: диагностика в Ubuntu 24.04
Определяем режим монтирования для каталога приложения и ищем предшествующие сообщения ядра. Команды не перемонтируют разделы и не исправляют файловую систему; результат помогает выбрать дальнейшую процедуру восстановления.
В этой статье
Ошибка Read-only file system означает, что операция записи упёрлась в ограничение доступной файловой системы или монтирования. Выдача дополнительных прав пользователю не обязана помочь. Сначала нужно определить, какое монтирование обслуживает проблемный путь и почему запись запрещена. Не начинайте с попытки принудительно вернуть режим записи.
Инструкция рассчитана на Ubuntu 24.04 LTS, findmnt из util-linux 2.39.3 и journalctl из systemd 255. Документация и синтаксис сверены 26 сентября 2026 года. Команды чтения выполнены в изолированной среде Ubuntu 24.04.3; там доступна контейнерная файловая система, но нет журнала ядра. Аварийный переход реального диска в режим чтения не воспроизводился, восстановление не тестировалось и здесь не предлагается.
Отделите запрет записи от нехватки прав
Сохраните точный текст ошибки приложения, время, операцию и полный путь к каталогу. Сообщение Permission denied указывает на иной класс ограничений и требует проверки владельца, прав и защитных механизмов. Сообщение No space left on device ведёт к проверке места и inode. Эти признаки могут встречаться в одном инциденте, но заменять один диагноз другим по общей фразе «не сохраняется файл» нельзя.
Если приложение показывает только общее сообщение, сначала найдите исходную ошибку в его журнале. Не создавайте пробные файлы в каталоге базы данных и не меняйте разрешения ради эксперимента. Для дальнейшего чтения состояния запись в проблемный каталог не нужна.
Найдите режим именно для нужного пути
Для существующего каталога /var команда выглядит так:
findmnt --target /var --output TARGET,SOURCE,FSTYPE,VFS-OPTIONS,FS-OPTIONS
Замените /var на существующий каталог, в котором приложение не может записать данные. Если имя содержит пробелы, заключите весь путь в кавычки. Проверка корня сервера вместо каталога приложения может показать другое монтирование и привести к ошибочному выводу.
Параметр --target выбирает файловую систему, обслуживающую указанный путь. Явно заданный --output оставляет нужные столбцы: TARGET — точка монтирования, SOURCE — источник, FSTYPE — тип. VFS-OPTIONS показывает параметры на уровне монтирования, а FS-OPTIONS — параметры файловой системы. Такое разделение полезно, когда одно представление данных ограничено сильнее другого.
Ищите отдельное значение ro или rw среди параметров. ro обозначает режим только чтения, rw — режим чтения и записи на соответствующем уровне. Если монтирование имеет ro, наличие rw у нижележащей файловой системы не делает этот путь доступным для записи. И наоборот, одно увиденное rw не доказывает, что приложение сможет писать: остаются права, защитные ограничения и особенности хранения.
В параметрах ext4 может встречаться errors=remount-ro. Это политика реакции на ошибку, а не доказательство того, что переход уже произошёл. Текущий режим и сообщения о событии нужно проверить отдельно. Не ищите просто подстроку ro во всём выводе: она может оказаться частью другого параметра.
Учтите среду, из которой смотрите
Команда показывает монтирования в пространстве имён текущего процесса. Если магазин работает в контейнере, вывод на хосте может отличаться от того, что доступно внутри контейнера. Диагностику выполняет администратор в нужной среде с разрешённым доступом; угадывать результат приложения по соседнему контейнеру нельзя.
В нашем локальном выполнении команда показала тип overlay и режим rw на обоих уровнях. Это подтверждает разбор синтаксиса и вывод столбцов в этой среде, но ничего не говорит о диске читателя. Источником также может оказаться сетевое хранилище. Тогда часть причин находится на стороне сервера хранения и не видна из виртуальной машины магазина.
Обычного пользователя часто достаточно для просмотра монтирований. Ошибка доступа или отсутствие пути — повод проверить контекст запуска и путь, а не автоматически повышать права всех файлов. Если вывод пустой, не считайте это доказательством исправности: сначала убедитесь, что команда выполнена успешно и указанный каталог существует в этой среде.
Посмотрите сообщения до отказа
При доступном системном журнале прочитайте сообщения ядра текущей загрузки за последние 30 минут:
journalctl --dmesg --boot --since "-30min" --no-pager
Для чтения системного журнала могут потребоваться права администратора или членство в разрешённой группе. Используйте уже предоставленный доступ; не меняйте группы и настройки журналирования ради этой инструкции. В контейнере журнал хоста часто недоступен независимо от наличия программы journalctl.
--dmesg ограничивает выборку сообщениями ядра, --boot — текущей загрузкой, --since задаёт начало интервала. --no-pager выводит результат без интерактивного просмотрщика. Если отказ произошёл раньше, расширьте интервал осмысленно: чрезмерно большой запрос может прочитать много данных и создать дополнительную нагрузку на хранилище.
Ищите сообщения об ошибках ввода-вывода, проблемах файловой системы и переходе в режим чтения. Сопоставляйте их с источником из findmnt и временем ошибки приложения. Одна строка о другом устройстве не объясняет сбой нужного каталога. Не ограничивайте поиск единственным словом: сообщения отличаются у разных файловых систем и драйверов.
В локальной проверке команда завершилась без записей и сообщила об отсутствии файлов журнала. Это ограничение наблюдения, а не доказательство отсутствия ошибок. Аналогично после перезагрузки текущая загрузка может уже не содержать события отказа. Понадобится доступная история или сведения администратора хоста, если они сохранились.
Где остановиться
Если подтверждён режим только чтения и рядом по времени есть ошибки хранения, дальнейшие действия зависят от типа файловой системы, состояния носителя и резервных копий. Не запускайте исправление на смонтированной рабочей базе, не подставляйте случайное устройство и не перемонтируйте его в запись только ради исчезновения сообщения. Сначала нужен план сохранения данных и восстановления для конкретной схемы.
Передайте ответственному специалисту точный путь, время, тип и источник монтирования, отдельные параметры VFS и файловой системы, а также относящиеся к инциденту строки журнала. Исключите секреты и данные покупателей. Такой пакет позволяет различить намеренно закрытый том, ограничение контейнера и реакцию на неисправность хранения — три ситуации, которым нужны разные дальнейшие действия.
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.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.