Команда mount -o remount,rw / применяется, когда файловая система смонтирована только для чтения и любая попытка записи возвращает ошибку Read-only file system — например, при редактировании конфигурации в /etc, изменении системного раздела Android или работе с флешкой, которая внезапно стала доступна только для чтения. Без перемонтирования в режим rw (read-write) изменить файлы на таком разделе невозможно, даже имея права root.
Опция -o remount позволяет изменить параметры уже смонтированной файловой системы без её отмонтирования — это ключевое преимущество, когда раздел занят запущенными процессами и обычный umount завершается ошибкой «device is busy». В этой статье разберём синтаксис команды, типичные сценарии применения, причины ошибок и способы их диагностики.
Синтаксис и принцип работы команды
Базовая форма команды выглядит так:
mount -o remount,rw /точка/монтированияЗдесь -o задаёт опции монтирования, remount указывает, что нужно изменить параметры существующего подключения, а rw переводит раздел в режим чтения и записи. Вместо точки монтирования можно указать устройство, например /dev/sda1, но на практике путь к смонтированному каталогу надёжнее и читаемее.
Чтобы понять, какие разделы сейчас смонтированы и в каком режиме, выполните:
mount | grep roВывод покажет строки с параметром ro — это и есть разделы в режиме «только чтение». Альтернативный способ — посмотреть содержимое файла /proc/mounts, где ядро публикует актуальные параметры всех смонтированных файловых систем.
Важно понимать: remount не проверяет файловую систему и не исправляет ошибки — он лишь меняет флаг доступа. Если раздел ушёл в read-only из-за повреждений, перемонтирование в rw может быть заблокировано ядром или привести к дальнейшей порче данных.
Типичные сценарии применения
Наиболее частая ситуация — корневая файловая система, загруженная в режиме ro. Такое происходит при загрузке в single-user mode (режиме восстановления), при сбоях в fstab или когда ядро обнаружило ошибки на диске и перевело раздел в защитный режим. Для восстановления записи достаточно:
mount -o remount,rw /Второй популярный сценарий — работа с системным разделом Android через adb shell или эмулятор терминала. На устройствах с root-доступом разделы /system и /vendor по умолчанию смонтированы как read-only, и для изменения системных файлов их перемонтируют:
mount -o remount,rw /systemТретий случай — USB-накопители и SD-карты. Если флешка монтируется только для чтения, возможные причины — ошибки файловой системы после небезопасного извлечения, физический переключатель защиты записи на карте или адаптере, а также аппаратный износ носителя, при котором контроллер сам блокирует запись.
- 🔧 Восстановление системы после загрузки в аварийном режиме с ro-корнем
- 📱 Изменение системных файлов Android при наличии root-прав
- 💾 Возврат записи на флешку после сбоя или некорректного извлечения
- 🖥️ Временное включение записи на разделе, который в
fstabсмонтирован как ro
Пошаговая инструкция по перемонтированию
Перед выполнением команды убедитесь, что у вас есть права суперпользователя — без них операция завершится ошибкой permission denied. Используйте sudo или переключитесь в root через su.
- Определите точку монтирования нужного раздела:
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS - Проверьте текущий режим — в колонке OPTIONS будет присутствовать
ro - Выполните
sudo mount -o remount,rw /точка/монтирования - Повторите проверку через
findmnt— параметр должен смениться наrw - Проверьте запись практически:
touch /точка/монтирования/testfile, затем удалите тестовый файл
☑️ Проверка перед remount в режим rw
Если команда отработала без сообщений, но запись всё равно невозможна, проверьте права на сам каталог и файлы — флаг rw на уровне монтирования не отменяет обычные Unix-права доступа. Также убедитесь, что на разделе есть свободное место: при заполненном на 100% разделе запись будет невозможна даже после успешного перемонтирования.
Почему раздел сам уходит в read-only
Ядро Linux переводит файловую систему в режим ro автоматически, когда драйвер ФС сталкивается с критической ошибкой — такое поведение задаётся параметром errors=remount-ro, который часто указан для корневого раздела в /etc/fstab. Это защитная мера: продолжать запись на повреждённую файловую систему опаснее, чем остановить её.
Диагностику стоит начать с просмотра журнала ядра:
dmesg | grep -iE "error|ext4|remount"Типичные записи — ошибки чтения блоков, сбои журнала ext4, сообщения о повреждении суперблока. Если такие строки есть, перемонтирование в rw — лишь временная мера: после перезагрузки или даже раньше раздел снова уйдёт в ro, а данные могут деградировать дальше.
⚠️ Внимание: если dmesg показывает ошибки ввода-вывода (I/O error) на диске, не спешите перемонтировать раздел в rw. Сначала скопируйте важные данные на другой носитель — каждая операция записи на сбоящий диск может ускорить потерю информации.
Отдельный случай — NTFS-разделы от Windows. Если Windows была завершена в режиме гибернации или с включённой быстрой загрузкой, Linux монтирует такой раздел только для чтения, поскольку файловая система находится в «грязном» состоянии. Здесь помогает либо полное выключение Windows с отключённым Fast Startup, либо принудительное монтирование с осознанием рисков.
Проверка и восстановление файловой системы
Для ext4 раздел отмонтируют (или загружаются с Live-USB) и выполняют fsck -y /dev/sdXN. Для NTFS из Linux базовую проверку делает ntfsfix, но полноценная проверка выполняется средствами Windows: chkdsk X: /f. Никогда не запускайте fsck на смонтированном разделе.
Ошибки при выполнении remount и их решение
Команда может завершиться неудачей с разными сообщениями. Разберём основные варианты и порядок действий для каждого.
| Ошибка | Вероятная причина | Что делать |
|---|---|---|
| mount: /: cannot remount rw | Ядро заблокировало запись из-за ошибок ФС | Проверить dmesg, выполнить fsck с Live-USB |
| permission denied | Нет прав root | Использовать sudo или su |
| mount point not found | Неверно указана точка монтирования | Уточнить путь через findmnt |
| device is busy | Раздел занят процессами (при обычном umount) | Использовать именно remount вместо umount |
| Read-only file system при записи после remount | Аппаратная блокировка записи или сбой контроллера флешки | Проверить переключатель на карте, протестировать носитель на другом устройстве |
Особого внимания заслуживает ситуация с флеш-накопителями: когда контроллер флешки исчерпывает ресурс ячеек памяти, он переводит носитель в постоянный режим read-only на аппаратном уровне. В этом случае никакая команда не вернёт возможность записи — данные можно только скопировать, после чего носитель подлежит замене.
⚠️ Внимание: на современных версиях Android раздел /system часто защищён механизмами verity и динамическими разделами (super). Простой remount,rw на таких устройствах может не сработать или нарушить проверку целостности — конкретный способ зависит от модели и версии прошивки, сверяйтесь с документацией именно вашего устройства.
Отличие remount от полного перемонтирования
Частый вопрос: зачем нужен remount, если можно отмонтировать раздел и смонтировать заново с нужными опциями? Ответ кроется в занятости ресурсов. Корневой раздел, раздел с запущенными программами или открытыми файлами отмонтировать невозможно — система вернёт ошибку target is busy.
Опция remount работает «на лету»: ядро просто обновляет флаги в структуре монтирования, не разрывая существующие файловые дескрипторы. Это делает команду единственным рабочим способом изменить режим корневой ФС без перезагрузки.
При этом у remount есть ограничение: он не позволяет сменить тип файловой системы или устройство — только опции монтирования (ro/rw, noexec, nosuid, relatime и другие). Для смены устройства потребуется полный цикл umount/mount.
Закрепление режима rw через fstab
Перемонтирование действует до перезагрузки. Если раздел должен постоянно монтироваться в режиме записи, настройку нужно внести в файл /etc/fstab. Найдите строку нужного раздела и убедитесь, что в поле опций указано rw или defaults (последнее включает rw по умолчанию), а не ro.
Пример строки для обычного раздела данных:
/dev/sdb1 /mnt/data ext4 rw,relatime 0 2После правки файла проверьте корректность синтаксиса командой sudo mount -a — она смонтирует всё из fstab и сообщит об ошибках, не дожидаясь перезагрузки. Ошибка в fstab может привести к тому, что система уйдёт в аварийный режим при следующей загрузке, поэтому эта проверка обязательна.
Частые вопросы
Чем отличается mount -o remount,rw от mount -o rw?
Опция rw без remount применяется при первичном монтировании устройства в каталог. Если раздел уже смонтирован, простая команда mount -o rw с теми же аргументами не изменит флаги — нужен именно remount, который модифицирует существующее подключение.
Почему после remount,rw раздел снова стал read-only?
Наиболее вероятная причина — повторная ошибка файловой системы или ввода-вывода, после которой ядро снова перевело раздел в защитный режим. Проверьте dmesg на наличие свежих ошибок и выполните проверку диска. Если ошибок нет, убедитесь, что какой-либо скрипт или сервис не перемонтирует раздел принудительно.
Можно ли перемонтировать корневой раздел без перезагрузки?
Да, именно для этого и существует remount: команда sudo mount -o remount,rw / меняет режим корневой ФС на лету, не прерывая работу системы. Полностью отмонтировать корень в работающей системе невозможно.
Флешка монтируется только для чтения — поможет ли remount?
Зависит от причины. Если дело в ошибках файловой системы после небезопасного извлечения, проверка ФС и повторное монтирование могут помочь. Если же контроллер флешки аппаратно заблокировал запись из-за износа памяти, программные методы бессильны — скопируйте данные и замените носитель.
Опасно ли перемонтировать /system в rw на Android?
Риски есть: изменение системных файлов может нарушить работу устройства, а на прошивках с проверкой целостности (dm-verity) запись в /system может быть заблокирована или привести к невозможности загрузки. Подход зависит от модели и версии Android — перед изменениями сделайте резервную копию и изучите инструкции именно для вашего устройства.