Вы пытаетесь сохранить файл или обновить службу на SUSE Linux Enterprise Server (SLES), и Linux отвечает сообщением «Файловая система только для чтения». Это сообщение может означать, что точка монтирования была намеренно установлена в режим только для чтения, вы загрузились из снимка Snapper в режиме только для чтения, или Btrfs обнаружила проблему и перестала принимать операции записи для защиты тома. Эти причины требуют разных действий. Начните с определения того, какая файловая система и точка монтирования задействованы; не выполняйте принудительное перемонтирование или команду восстановления, не проверив журналы ядра и не защитив важные данные.
Что означает эта ошибка
Btrfs — это файловая система Linux с механизмом копирования при записи, используемая по умолчанию в качестве корневой файловой системы SLES во многих стандартных установках. Подтом Btrfs — это независимо монтируемая часть файловой системы; снимок — это копия подтома на определенный момент времени, которая содержит неизмененные блоки данных. Snapper и меню загрузки SLES могут использовать снимки для восстановления после изменений в системе. При загрузке снимка включенные в него части монтируются только для чтения. Кроме того, Btrfs может переключаться в режим только для чтения после обнаружения определенных структурных ошибок, чтобы избежать дальнейшей записи. SUSE описывает поведение снимков в своем руководстве по Snapper для SLES 15 SP7 ; в документации по проверке дерева файлов проект Btrfs объясняет, что структурные проверки файловой системы могут переключать том в режим только для чтения, чтобы предотвратить дальнейшее повреждение . Точные названия пунктов меню и доступные параметры восстановления могут различаться в зависимости от пакета обновлений SLES и структуры хранилища.
Проблема с правами доступа — это другое дело. Сообщение «Доступ запрещен» обычно указывает на права собственности или управления доступом; сообщение «Файловая система доступна только для чтения» (часто обозначается как EROFS) указывает на состояние файловой системы или подтома. Изменение прав доступа к файлу с помощью команды chmodне сделает монтирование, доступное только для чтения, доступным для записи.
Прежде чем что-либо менять
Если это производственный сервер, том базы данных или единственная копия важных данных, свяжитесь с системным администратором и подтвердите наличие резервной копии, прежде чем пытаться восстановить данные. Пока система еще доступна для чтения, скопируйте наиболее важные файлы на отдельное исправное хранилище, если это возможно без дополнительной нагрузки на неисправное устройство. После критической ошибки в памяти файловой системы Btrfs могут храниться только последние изменения метаданных; отключение или перезагрузка могут привести к потере этих незафиксированных изменений. Если в журналах упоминаются ошибки ввода-вывода, исчезновение устройств или повторные сбросы, отдайте приоритет восстановлению работоспособности хранилища и защите данных, а не восстановлению записей.
Не запускайте этот процесс btrfs check --repairв качестве стандартного первого шага. Проект Btrfs предупреждает, что режим восстановления может привести к повреждениям и не может исправить все виды повреждений. Также не следует многократно принудительно выполнять перемонтирование с возможностью чтения и записи: оно может сразу же завершиться неудачей, если ядро по какой-либо причине защитило файловую систему.
Шаг 1: Определите поврежденное крепление.
Используйте путь, по которому произошла ошибка записи. Например, если служба не может записать данные в указанный /srv/appпуть, проверьте его, а не предполагайте, что проблема в корневой файловой системе:
findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS
Замените /srv/appна соответствующий файл или каталог. Проверьте вывод на наличие источника Btrfs, целевого объекта монтирования и параметра roили rw. Целевым объектом может быть /, отдельный монтированный каталог данных или подтом. Запишите источник и целевой объект перед продолжением. Если команда сообщает о другом типе файловой системы, действия, специфичные для Btrfs, к этому пути не применяются.
Проверьте сообщения ядра за текущую загрузку, чтобы узнать причину перехода файловой системы в режим только для чтения:
sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'
Ищите сообщения об ошибках Btrfs или «принудительно только для чтения», ошибки контрольной суммы или дерева, сбои ввода-вывода устройств и отключения устройств. Строка в журнале — это лишь подсказка, а не полный диагноз. Сохраните соответствующие сообщения и метки времени перед перезагрузкой, поскольку журналы могут быть полезны для группы поддержки хранилища или оборудования.
Шаг 2: Проверьте наличие преднамеренного снимка, доступного только для чтения.
Если сервер был запущен из загрузочного снимка в GRUB, файлы, включенные в этот снимок, по умолчанию доступны только для чтения. Это среда восстановления для проверки предыдущего состояния системы; она не является автоматически окончательно восстановленной системой. Подтвердите загрузку с администратором, затем перезагрузите систему и выберите обычную загрузку SLES по умолчанию, если загрузка из снимка была случайной. В документации SUSE указано, что загрузка из снимка монтирует включенные в него части файловой системы только для чтения, а отдельная процедура отката описана в руководстве по восстановлению SLES 15 SP7 Snapper .
Конкретный снимок может быть доступен только для чтения, даже если родительская файловая система смонтирована в режиме чтения и записи. Если вы намеренно работаете со снимком, просмотрите его, не внося изменений:
sudo btrfs property get -t subvol /path/to/subvolume ro
Замените путь на путь монтирования подтома. Результат ro=trueподтверждает, что свойство подтома доступно только для чтения; этот флаг описан в справочнике свойств Btrfs . Не следует просто переводить управляемый Snapper или полученный резервный снимок в режим чтения/записи: статус «только для чтения» может быть частью предположений о восстановлении или инкрементном резервном копировании. Используйте поддерживаемый рабочий процесс Snapper или создайте отдельный записываемый подтом, если это является необходимой задачей.
Шаг 3: Проверьте конфигурацию монтирования и состояние хранилища.
Если findmntв отчетах roи журналах не отображаются ошибки Btrfs или ввода-вывода, проверьте соответствующую запись монтирования в /etc/fstab. Возможно, монтирование было намеренно настроено только для чтения для восстановления, образа устройства или политики защиты данных. Изменяйте конфигурацию только после подтверждения желаемого состояния с владельцем службы. Также проверьте, использует ли система транзакционное развертывание или развертывание с корневым каталогом только для чтения: SLES описывает такие конфигурации и порядок их обслуживания в своем руководстве по транзакционным обновлениям . Если запись явно предназначена для записи, устройство исправно, и путь не является снимком только для чтения, администратор может попытаться временно перемонтировать:
sudo mount -o remount,rw /mountpoint
Замените /mountpointна точное целевое значение, указанное в findmnt. Это не диагностирует и не исправляет повреждения. Если операция завершится неудачей, вернет ошибку или в журналах ядра появятся проблемы с хранилищем, остановитесь и перейдите к планированию восстановления, а не повторяйте попытку с дополнительными параметрами.
В случае возможной проблемы с пропускной способностью проверьте распределение файловой системы Btrfs и состояние устройства:
sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint
Компания SUSE отмечает, что обычные сводки о свободном месте на диске могут вводить в заблуждение при использовании Btrfs, поскольку данные и метаданные выделяются отдельно. Снимки Snapper также могут занимать значительное пространство. Однако сообщение «Нет места на устройстве» не идентично ошибке Btrfs, приводящей к невозможности чтения; необходимо определить, какое именно сообщение получило приложение. Не удаляйте снимки только для проверки теории. Сначала подтвердите их содержимое и следуйте применимой политике хранения. См. руководство по устранению неполадок файловой системы SLES 15 SP7 .
Шаг 4: Решите, требуется ли восстановление файловой системы.
Если в журнале ядра появляются ошибки Btrfs, устройство отсутствует или повторное монтирование отклонено, сохраните журналы и подготовьте проверенную резервную копию или снимок на уровне хранилища перед началом ремонтных работ. Для тома данных, не являющегося корневым, запланируйте окно обслуживания и отмонтируйте его перед проверками в автономном режиме. Для корневой файловой системы используйте установочный или восстановительный носитель SUSE и следуйте процедуре, соответствующей конкретной версии SLES и сигнатуре ошибки. Не пытайтесь угадать имя устройства: файловая система Btrfs может охватывать несколько устройств, поэтому сначала определите всех участников и правильные идентификаторы монтирования или устройства.
В руководстве по администрированию SUSE SLES 15 SP7 есть специальный раздел, посвященный корневому разделу Btrfs, который не удается смонтировать. В нем обсуждаются варианты восстановления при такой ошибке загрузки. Эти инструкции не означают, что журнал каждой смонтированной файловой системы только для чтения следует очищать. В руководстве по btrfs-rescue поясняется, что btrfs rescue zero-logэто необходимо для определенных случаев сбоя воспроизведения журнала во время монтирования, и это может привести к отмене изменений с момента последней зафиксированной транзакции. Используйте это только тогда, когда зарегистрированная ошибка соответствует описанному случаю, и план восстановления учитывает возможную потерю данных.
btrfs checkПо умолчанию btrfs-check запускается в режиме только для чтения на несмонтированной файловой системе. Оставьте его в таком режиме для первоначальной оценки и поделитесь результатами проверки со службой поддержки SUSE или специалистом по Btrfs. В руководстве по использованию btrfs-check прямо указано, что его не следует использовать --repairбез консультации с опытным пользователем или разработчиком. Никогда не запускайте автономную проверку на смонтированной, изменяющейся файловой системе.
Шаг 5: Проверка восстановления
После устранения причины перезагрузки выполняйте ее только тогда, когда этого требует план восстановления. Затем findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONSснова используйте устройство и убедитесь, что монтирование находится в режиме чтения-записи. Проверьте журнал ядра на наличие новых ошибок Btrfs или ошибок ввода-вывода. Наконец, убедитесь, что затронутая служба или приложение могут нормально функционировать, и подтвердите, что резервная копия остается доступной. Само по себе успешное перемонтирование не доказывает работоспособность хранилища.
Если файловая система возвращается в режим только для чтения, устройство отключается или ошибки продолжаются, запись останавливается, и проблема усугубляется с помощью сохраненных журналов, findmntвывода, списка устройств Btrfs, уровня пакета обновлений SLES и сведений о контроллере хранилища. Эти данные помогают отличить преднамеренный снимок или параметр монтирования от повреждения носителя, соединения, драйвера или файловой системы — и позволяют избежать превращения защитного состояния только для чтения в более серьезную проблему восстановления.