Короткий ответ

Ядро переводит ext4 в read-only при I/O error (errors=remount-ro в fstab — поведение по умолчанию). Это защита данных, не «сломался chmod». Сначала dmesg/journalctl -k: есть ли I/O error, Buffer I/O error, medium error. Пока диск врёт, mount -o remount,rw только ускорит порчу. Снимите нагрузку, проверьте гипервизор/SMART/кабель, затем либо устраните путь к устройству и аккуратно верните rw, либо umount и fsck с копией.

Хост host.example (10.0.20.10). Путают с EACCES — там Permission denied.

Симптомы и как отличить

  • touch /tmp/x → Read-only file system;
  • findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS / содержит ro;
  • SSH ещё работает, если сессия в памяти, но sudo может не писать sudoers timestamp;
  • ENOSPC при rw — другая статья про диск.
СообщениеДействие
I/O error + remount-roжелезо/LUN, не fsck сразу
только ro в fstabконфиг, не авария диска
NFS roэкспорт сервера
quotaне ro, а EDQUOT

Возможные причины

  1. Реальный сбой диска/контроллера/USB.
  2. Потеря LUN iSCSI, snapshot freeze гипервизора «навечно».
  3. Thin pool datastore 100% — гость видит I/O error.
  4. Явно errors=remount-ro сработал после journal abort.
  5. Админ сделал mount -o remount,ro или fstab ro.
  6. Overlayroot/cloud-image в каком-то live режиме (редко на server LTS).

Диагностика

findmnt -A -o TARGET,SOURCE,FSTYPE,OPTIONS
cat /proc/mounts | awk '$2=="/" {print}'
grep -v '^#' /etc/fstab
dmesg -T | grep -iE 'i/o error|read-only|ext4|xfs|blk_update' | tail -n 50
journalctl -k -b --no-pager | grep -iE 'I/O error|Remounting|ext4' | tail

Устройство корня:

lsblk -o NAME,RO,STATE,TYPE,FSTYPE,MOUNTPOINT
cat /sys/block/vda/ro
smartctl -H /dev/sda 2>/dev/null

RO 1 на блочном устройстве — гипервизор/LUN read-only, гостевой remount бесполезен.

Дисковое место путать нельзя:

df -h
df -i

100% иногда предшествует странным ошибкам записи, но сообщение всё равно должно быть ENOSPC, не remount-ro.

Сохраните в заявку:

sudo mkdir -p /root/ro-diag
sudo dmesg -T > /root/ro-diag/dmesg.txt
# если корень уже ro, пишите на другой том или консоль

Если корень ro, запись в /root не выйдет — используйте journalctl в буфер консоли или смонтированный /data если он ещё rw.

Решение

Сценарий A. Ложный ro: так в fstab

sudo mount -o remount,rw /
findmnt /

Исправление fstab постоянно. Причина должна быть понятна (был maintenance).

Сценарий B. Краткий freeze гипервизора, диск снова жив, dmesg без medium error

После подтверждения, что dd if=/dev/vda of=/dev/null bs=1M count=10 не сыпет ошибки:

sudo mount -o remount,rw /

Сразу проверьте приложения. Если ошибки I/O продолжаются — откатите remount (снова ro) и чините storage.

Сценарий C. Есть medium/I/O error

  1. Snapshot/backup сейчас, если том ещё читается.
  2. Уменьшите I/O, остановите БД штатно, если успеете.
  3. Планируйте umount или загрузку live и fsck — следующая статья.
  4. Не делайте tune2fs -e continue чтобы «не уходило в ro»: вы отключите предохранитель.

Сценарий D. Блочное устройство RO=1

Чините флаг на СХД/гипервизоре. В госте:

cat /sys/block/vda/ro

Пока 1 — только чтение.

Сценарий E. Не корень, а /data

Проще: остановить сервис, umount, проверка, mount rw. Корень так не отмонтировать без live.

Порядок возврата rw, когда корень уже read-only

Писать скрипты в /root нельзя. Используйте:

  • консоль гипервизора и копирование вывода руками;
  • если /dev/shm tmpfs ещё rw — туда (/dev/shm/ro-diag.txt);
  • live ISO.

mount -o remount,rw / вернёт код 0 даже когда следующее write снова уронит ФС в ro. Поэтому после remount сразу:

dmesg -T | tail -n 20
dd if=/dev/zero of=/tmp/.rw-probe bs=1M count=8 conv=fsync
rm /tmp/.rw-probe

Если dd ловит I/O error — верните ro (или не трогайте) и занимайтесь диском. Повторный remount в цикле — способ добить ext4 journal.

На XFS сообщение другое: xfs_log_force: error. Не применяйте e2fsck к xfs. xfs_repair только на umount/live.

Опция fstab errors=panic вместо remount-ro даст reboot-loop на сбое диска. Для сервера БД обычно хуже, чем работать в ro и алертить. Оставляйте errors=remount-ro.

Если read-only случился во время apt-get upgrade, база dpkg могла остаться полузаписанной. После возврата rw не reboot сразу: dpkg --audit и dpkg --configure -a, иначе следующий старт упрётся в lock и загрузку. Пишущие сервисы (postgres, mysql) после ro часто требуют systemctl restart — WAL мог не дописаться; смотрите их собственные логи на read-only/EIO, не только findmnt.

На NVMe в гипервизоре с discard/thin fstrim в момент деградации datastore усиливает I/O error. Отключите timer fstrim.timer до починки СХД:

systemctl status fstrim.timer fstrim.service --no-pager

Не mount -o remount,rw,discard «для ускорения» на больном томе.

Как проверить, что проблема устранена

findmnt -n -o OPTIONS /
touch /tmp/.rw-ok && rm /tmp/.rw-ok
dmesg -T | tail
systemctl is-system-running

Пишущий сервис (БД) должен пройти свой check. Мониторинг I/O errors с dmesg после часа нагрузки.

С admin@10.0.20.10: удалённый touch по SSH.

Если не помогло

  • Сразу снова ro: диск умирает, планируйте миграцию, не цикл remount.
  • Только один LV: смотрите этот PV.
  • XFS Shut down filesystem: свой путь (xfs_repair только offline).
  • После fsck не грузится: загрузка.

Профилактика

  • Алерт по findmnt ro и по kernel I/O error.
  • Не держать единственную копию БД на одном виртуальном диске без snapshot.
  • errors=remount-ro оставить; errors=panic только если хотите немедленный reboot (спорно).
  • Тестировать backup restore, не только «диск зелёный в панели».

FAQ

Почему SSH жив на ro корне?

sshd уже в RAM, ключи прочитаны. Новые сессии, запись wtmp/auth могут отказать.

mount -o remount,rw безопасен?

Только если I/O path здоров. Иначе вы продолжите писать в умирающий диск.

Это из‑за заполненного диска?

Обычно нет. Заполнение даёт ENOSPC. Исключение: кривые драйверы, но dmesg всё равно нужен.

Можно ли blockdev --setrw?

Не лечит сбой носителя. На LUN с флагом RO может кратко сработать и снова отвалиться.

journald на ro

Пишет в /run если может. После rw верните persistent — journald и диск.