Файл read only как исправить

Ошибка read only file system может возникнуть при загрузке с LiveCD диска или в режиме восстановления вашего дистрибутива. Она означает, что файловая система в которую вы пытаетесь вести запись примонтирована только для чтения. Этому может быть несколько причин. Есть файловые системы, которые доступны только для чтения это файловая система оптических дисков — ISO, а также файловая система образов SquashFS.

С такими файловыми системами вы сделать ничего не сможете. Для изменения данных в них, надо распаковать образ, изменить данные и запаковать его обратно. Но что касается обычных файловых систем, таких как EXT4, BTRFS, XFS, то их можно монтировать и для чтения и для записи.

В этой небольшой статье мы рассмотрим как исправить read only file system Linux перемонтировав файловую систему для записи. Первым делом надо определиться с точкой монтирования, для которой надо разрешить запись. Попытаемся создать файл в корневом каталоге:

touch /file

Ошибка, файловая система корневого каталога доступна только для чтения. Чтобы посмотреть все точки монтирования доступные в системе выполните в терминале:

mount | grep /dev/sd

В данном случае, корневая файловая система и есть точкой монтирования. Но у вас, например, возникнут проблемы с созданием файла в домашней папке, то надо будет уже перемонтировать /home. Смотрите внимательно. Когда точка монтирования выбрана, осталось её примонтировать с правами на запись:

sudo mount -o remount,rw /

Или для /home:

sudo mount -o remount,rw /home

После этого вы сможете создать файл без каких-либо проблем. После завершения работы, во избежание повреждения данных при перезагрузке, желательно перемонтировать файловую систему обратно в режим только для чтения:

sudo mount -o remount,ro /

Теперь вы знаете что означает эта ошибка и как с ею справится. Если у вас остались вопросы, спрашивайте в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

В некоторый случаях файловая система в Linux может перейти в состояние read-only, при котором вы можете только читать данные с диска, а при попытке записи любых изменение или создании нового файла появдляется ошибка Read-only file system.

Ошибки файловой системы и опция remount-ro

Проверьте параметры монтирования дисков при загрузке Linux. Настройки монтирования файловых систем при загрузке задаются в файле /etc/fstab.

$ cat /etc/fstab

опции понтирования файловой системы в linux fstab при наличии ошибок

Обратите что в fstab есть строка монтирования корневой директории вида:

UUID=aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa / ext4 errors=remount-ro 0 1

Параметр
errors=remount-ro
означает, что данная директория будет смонтирована в режиме чтения, если на файловой системе устройства обнаружены проблемы. В этом случае нужно выполнить проверку диска с помощью FSCK.

Обычные файловые системы такие как EXT4/BTRFS/XFS можно монтировать как в режиме записи, так и только для чтения (в отличии от файловых систем ISO или SquashFS, которые доступны только для чтения).

В случае обнаружения ошибок на диске вы можете использовать одну из трех опций
errors=[continue|remount-ro|panic]

  • continue – игнорировать ошибки,
  • remount-ro – перемонтировать диск в режиме только для чтения
  • panic – остановить загрузку системы

Вы можете вывести соответствие между UUID диска и именем устройства:

$ sudo blkid

В данном примере вы получили, что вашему UUID соответствует устройство /dev/sda3.

blkid вывести uuid и /dev/sdx имя

Также можно имена устройства и точки монтирования с помощью команды:

$ df –h

точки монтирования и файловые системы в linux

Т.к. в данном примере ошибки обнаружены в корневой директории которая является точкой монтирования, вы сможете выполнить ее проверку только загрузившись с LiveCD. Для исправления ошибок файловой системы используется команда:

$ sudo fsck –y /dev/sda3

Или

$ sudo fsck –y UUID=aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa

Если вы не можете прямо сейчас выполнить проверку диска, и вы хотите немедленно вывести файловую систему из режима read-only, нужно выполниться команду:

$ sudo mount -o remount,rw /

Обязательно запланируйте проверку файловой системы на ближайшее время.

Read-only файловая система в виртуальных машинах

Файловая система раздела Linux на виртуальной машине можете перейти в read-only в случае недоступность системы хранения данных (СХД). Самый простой способ восстановить работу ОС – выполнить сброс виртуальной машины (фактически перезапуск с параметрами по умолчанию).

Может оказаться, что ВМ с Linux вообще не загружается и вам доступна только командная строка initramfs с предупреждениями:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY.
Fsck exitrd with code 4.
 The root file system of /dev/sdx requires a manual fsck.

ошибка проверки файловой системы fsck в initramfs

Initramfs это начальная файловая система в оперативной памяти, которая основана на tmpfs, которая содержит утилиты и скрипты, необходимые для работы с дисками, файловыми системами и тд. После запуска initramfs отобразится проблемная ситуация.

Если же ошибок нет – просто вводим exit. Иначе выполняем проверку диска:

$ fsck /dev/sda3 –y

Здесь указан том (в данной случае /dev/sda1), для которого требуется выполнить ручную проверку. С помощью следующей команды можно проверить все подключенные файловые системы:

$ fsck –A –y /dev/sda1

После этого перезагрузите ВМ.

     Файловая система может быть повреждена из-за различных неполадок или внезапного отключения компьютера. При обычном выключении все файловые системы монтируются только для чтения, а все несохраненные данные записываются на диск. Но если питание выключается неожиданно, часть данных теряется. Соответственно, могут быть потеряны важные данные, что приведёт к повреждению самой файловой системы.
     Одной из проблем может стать временная недоступность системы хранения данных (СХД). Виртуальные машины (ВМ) на ОС Linux очень чутко реагируют на подобные явления, переходя в Read Only.

В этой статье мы рассмотрим варианты решения данного вопроса:

Первый и самый простой способ — это перезагрузка «Виртуальной машины»

Чтобы перезагрузить виртуальную машину:

  1. Нажмите левой кнопкой мыши на раздел «Virtual Machines» в левой области интерфейса vCloud Director. (рис. 1. действие 1)
  2. Найдите нужную вам виртуальную машину в основной области интерфейса. (рис. 1. действие 2)
  3. Нажмите левой кнопкой мыши на раскрывающееся меню «Actions» под описанием виртуальной машины. (рис. 1. действие 3)
  4. В выпадающем списке выберите опцию «Reset» и нажмите её левой кнопкой мыши. (рис. 1. действие 4)


Рисунок 1. VMware Cloud Director — Vritual Machines, перезагрузка виртуальной машины.

Во втором случае Linux не загружается, пользователю доступна только командная строка initramfs

Рисунок 2. Командная строка с initramfs

*Initramfs – это начальная файловая система в ОЗУ, основанная на tmpfs, которая не использует отдельное блочное устройство. Как и initrd, она содержит утилиты и скрипты, требуемые для монтирования файловых систем перед вызовом init, который располагается на корневой файловой системе.

Если вы не видите такой ошибки, попробуйте ввести exit в окне терминала. Ошибка может появиться после этого:

 (initramfs) exit

В ошибке указан том (в нашем случае sda1), который требует запуска ручной проверки диска. В командной строке initramfs выполните:

 fsck /dev/sda1 –y

Также с помощью флага -A вы можете проверить все файловые системы, подключённые к компьютеру:

 fsck -Ay /dev/sda1 

После полной проверки необходимо перезапустить систему.

Если система не переходит в initramfs, необходимо загрузиться с LiveCD

В этом случае необходимо примонтировать iso образ LiveCD к нашей виртуальной машине. В нашей базе знаний есть статья о том, как добавить свой образ в каталог:  

Для этого необходимо:

  1. Нажмите левой кнопкой мыши на раздел «Virtual Machines» в левой области интерфейса vCloud Director. (рис. 3. действие 1)
  2. Найдите нужную вам ВМ в основной области интерфейса.
  3. Нажмите левой кнопкой мыши по раскрывающемуся меню «Actions» под описанием ВМ . (рис. 3. действие 2)
  4. В выпадающем списке выберите опцию «Media» и нажмите на неё левой кнопкой мыши. (рис. 3. действие 3)
  5. В выпадающем списке выберите опцию «Insert Media» (рис. 3. действие 4)
      
    Рисунок 3. VMware Cloud Director — Vritual Machines, примонтирование ISO образа.
  6. В появившемся окне выберите LiveCD образ, который предварительно нужно загрузить в ваш «каталог». В качестве примера мы используем gpartedlive (рис. 4 действие 1), но можно использовать любой другой. После выбора iso-образа нажмите «insert» (рис. 4 действие 2)

    Рисунок 4. Выбор ISO-образа LiveCD: gparted-live
  7. Далее в настройках BIOS переключитесь на загрузку с CD. Для этого необходимо попасть в меню виртуальной машины. Нажмите на её имя, чтобы попасть в это меню (цифра один на рис. 5 — имя вашей ВМ).
  8. В «General» (справа) выберите Edit (рис.5 действия 2 и 3 соответственно).

    Рисунок 5. Меню виртуальной машины
  9. В появившемся окне необходимо поставить значение Boot Delay от «5» (задержка загрузки, необходимая для нажатия клавиши, чтобы попасть в BIOS). Перевести переключатель «Enter BIOS setup» во включенный режим. Нажмите «Save». (рис. 6, действия 1-3 соответственно).

    Рисунок 6. Настройки параметра General
  10. После запуска машины через «Power on, Force Recustomization» дождитесь загрузки ВМ и откройте «VM console», чтобы попасть в окно BIOS. (рис. 7 действие 1-2)

    Рисунок 7. Включение виртуальной машины с применением измененных настроек
  11. Во вкладке «Boot» «поднимите» значение CD-ROM на самый вверх. Выберите его и нажмите «+» на клавиатуре несколько раз, пока CD-ROM не займёт первую позицию. Это позволит системе загрузиться с нашего примонтированного образа (gparted-live)(рис.8)

    Рисунок 8. Меню BIOS виртуальной машины.
  12. Перейдите во вкладку «Exit» и выберите «Save and exit».
  13. Виртуальная машина загрузится с нашего образа. В появившемся окне выбираем первый пункт и нажмите «Enter».
  14. Выберите «Dont touch keymap» и нажмите «Enter». (рис. 9)


    Рисунок 9. Запуск gparted-live

  15. Введите «24» — русский язык, затем «Enter»
  16. Далее введите «0» и снова «Enter».
  17. Система загрузилась. Автоматически откроется окно утилиты Gparted. Закройте его и откройте «terminal» (рис. 10)

    Рисунок 10. Запуск терминала
  18. В появившемся окне терминала введите команду:
     sudo fsck -y -f -c /dev/sda1

    если увидите ошибку, то скорее всего нужно отмонтировать данный раздел:

     sudo umount /dev/sda1

    Ключи и параметры команды fsck:
    y — всегда отвечать yes на все вопросы (имеется альтернатива: ключ p — начинает проверку в полностью автоматическом режиме);
    f — принудительная проверка файловой системы (даже если файловая система помечена как полностью работоспособная)
    c — ищет битые блоки (bad blocks), а после отмечает их соответствующим образом/dev/sda1 — устройство или раздел, которые нужно проверить.

    Вывод терминала после проверки в нашем случае:
    ubuntu@ubuntu:~$ sudo fsck -y -f -c /dev/sda1fsck from util-linux 2.20.1e2fsck 1.42.5 (29-Jul-2012)
    Checking for bad blocks (read-only test): 0.00% done, 0:00 elapsed.
    (0/0/0 errdone
    /dev/sda1: Updating bad block inode.
    Pass 1:Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information/dev/sda1:
    ***** FILE SYSTEM WAS MODIFIED *****
    /dev/sda1: 372991/1921360 files (0.2% non-contiguous), 2539924/7680000 blocks
    ***** FILE SYSTEM WAS MODIFIED *****
    Это системное сообщение говорит, что текущая файловая система модифицировалась программой fsck.

После всех операций нужно перезагрузиться и отмонтировать образ от виртуальной машины. Для этого нажмите «Eject media» (рис.11 действие 1-4).


Рисунок 11. «Отмонтирование» LiveCD образа из виртуальной машины


Если на 18 пункте у вас возникли трудности, проследуйте следующим инструкциям- проверим разметку дисков командой: > lsblk

Пример вывода команды:

Из вывода команды видим, LVM назван ubuntu—vg-root, однако мы не можем запустить fsck на это имя, так как команда не найдёт его. Нужно получить полное имя, для этого нужно запустить команду lvm lvscan для получения LV имени с которым мы можем запустить fsck на LVM.

 sudo lvscan

Пример вывода команды:

Видим имя диска который нужно проверить на ошибки это /dev/ubuntu-vg/root, оно должно подойти для запуска fsck на этом имя.

Если /dev/ubuntu-vg/root не в состояние ACTIVE , необходимо сделать его активным, для этого используйте команду:

sudo lvchange -ay /dev/ubuntu-vg/root

Запускаем форсированную проверку с автоматическим исправлением ошибок fsck для проверки тома LVM :

 sudo fsck -fy /dev/ubuntu-vg/root


После всех операций нужно перезагрузиться

sudo reboot -f

И отмонтировать образ от виртуальной машины. Для этого нажмите «Eject media» (рис.11 действие 1-4). 

Ещё не пробовали услугу «Облачный хостинг» от Cloud4Y?

Отправьте заявку сейчас и получите 14-ти дневный бесплатный доступ.

СМОТРЕТЬ ПОДРОБНОСТИ             ПОПРОБОВАТЬ БЕСПЛАТНО

Содержание

  1. Как исправить read only file system в Linux
  2. Ошибка read only file system в Linux
  3. Исправление ошибок файловой системы Ubuntu «Файловая система доступна только для чтения»
  4. Неисправность носителя
  5. Форматирование
  6. Проверка на наличие ошибок
  7. GParted
  8. Права доступа
  9. USB-устройства отображаются только для чтения
  10. 12 ответов
  11. Файловая система доступна только для чтения
  12. Содержание
  13. Важно [ править ]
  14. Диагностика [ править ]
  15. Примечание [ править ]
  16. Исправление [ править ]
  17. Поиск сбойного блока [ править ]
  18. Отбраковка сбойного блока [ править ]
  19. Поиск повреждённого файла [ править ]
  20. Примечания [ править ]
  21. Приложение [ править ]

Как исправить read only file system в Linux

С такими файловыми системами вы сделать ничего не сможете. Для изменения данных в них, надо распаковать образ, изменить данные и запаковать его обратно. Но что касается обычных файловых систем, таких как EXT4, BTRFS, XFS, то их можно монтировать и для чтения и для записи.

Ошибка read only file system в Linux

В этой небольшой статье мы рассмотрим как исправить read only file system Linux перемонтировав файловую систему для записи. Первым делом надо определиться с точкой монтирования, для которой надо разрешить запись. Попытаемся создать файл в корневом каталоге:

Ошибка, файловая система корневого каталога доступна только для чтения. Чтобы посмотреть все точки монтирования доступные в системе выполните в терминале:

Snimok ekrana ot 2020 06 06 16 53 28

В данном случае, корневая файловая система и есть точкой монтирования. Но у вас, например, возникнут проблемы с созданием файла в домашней папке, то надо будет уже перемонтировать /home. Смотрите внимательно. Когда точка монтирования выбрана, осталось её примонтировать с правами на запись:

После этого вы сможете создать файл без каких-либо проблем. После завершения работы, во избежание повреждения данных при перезагрузке, желательно перемонтировать файловую систему обратно в режим только для чтения:

Теперь вы знаете что означает эта ошибка и как с ею справится. Если у вас остались вопросы, спрашивайте в комментариях!

Источник

Исправление ошибок файловой системы Ubuntu «Файловая система доступна только для чтения»

Операционная система Убунту хоть и превосходит по некоторым параметрам Windows, но тоже способна портить пользователю настроение, выдавая ошибки. Одна из таких — недоступность файловой системы. Причём касается это как обычных флешек, так и жёстких дисков в некоторых ситуациях. Решить проблему можно. Однако и опытные пользователи не всегда знают, как исправить ошибку, когда Ubuntu выдаёт: «Файловая система доступна только для чтения». Ответ мы постарались дать в этой статье.

oshibka dostupa k fajlam v ubutu

Причин возникновения проблем с доступом к файлам в Ubuntu может быть несколько.

Неисправность носителя

В первую очередь стоит проверить, точно ли исправна эта файловая система. В случае с флеш-картой сделать это легко. Попробуйте открыть её с компьютера на Windows. Другая система может быстро найти неполадки на накопителе. То же самое касается карт памяти, китайских плееров и других дешёвых носителей информации. Часто дело может быть в них.

В случае, когда проблемным является жёсткий диск, выполнить проверку будет гораздо труднее. Если на вашем компьютере стоит две системы, проверьте, исправно ли работает ваш HDD на Windows. Эти способы позволят определить очаг неисправности.

Форматирование

Во многих случаях вернуть работоспособность помогает простое форматирование файловой системы. Особенно легко это сделать на флешке. Правда, не всегда мы готовы расстаться с той информацией, которая на ней уже есть. Перекиньте все данные на компьютер под управлением Виндовс и отформатируйте проблемный накопитель.

С диском навряд ли у кого-то поднимется рука совершить такое. Форматирование может уничтожить много важной информации. Тем более, если повреждена файловая система Ubuntu, проблему надо искать в другом месте.

formatirovanie diska ubuntu

Проверка на наличие ошибок

Проверить диск на наличие ошибок можно не только на Windows. Убунту также обладает достаточным арсеналом для этого. Сделать это можно и с помощью команд, и пользуясь специальным приложением. Сначала разберём способ, использующий стандартные средства.

Просматриваем список накопителей:

Проверяем конкретный накопитель:

В примере взят sdf, но у вас название диска может отличаться.

Если том был примонтирован, то перед тем, как проверять, это действие нужно отменить:

Теперь проверяем том на бэдблоки — проблемные области:

Прогресс выполнения будет отображаться в процентах.

Теперь отмечаем бэдблоки, чтобы система перестала их использовать:

Такой способ в теории должен помочь исправить неполадки с любыми видами носителей. Если же сканирование дисков на ошибки не помогло, то пора воспользоваться удобной утилитой — GParted.

GParted

ubuntu gparted download

Права доступа

Наконец, последняя причина, по которой мы теряем доступ к управлению данными на носителях, заключается в нарушенных правах. С ней могут сталкиваться и опытные юзеры, использующие root-режим. Когда мы используем различные команды, не до конца понимая их суть, или запускаем программы с расширенными полномочиями, система может по ошибке перекрыть доступ.

proverka prav dostupa

После чего мы видим сообщение от Ubuntu: «Файловая система доступна только для чтения». Убрать такую неполадку помогут специальные команды.

В качестве универсального метода здесь подойдёт команда:

Вместо [user] необходимо вписать имя пользователя. Команда chown отвечает за смену прав доступа к папке. Атрибут –R означает, что этот раздел пользователь может только читать. Sudo отменяет эти изменения. В примере проблема заключалась в домашнем разделе, если у вас проблемы с флешкой, то следует вписать её директорию.

Файловая система Убунту работает немного по другим принципам, нежели на Windows. Поэтому любые диски под её управлением ведут себя по-другому. Из-за этого возникают и новые ошибки, с которыми на Винде нельзя столкнуться.

Теперь мы знаем, как решить проблему, касающуюся неполадок с редактированием дисков. Дело может быть как в неисправности устройств, так и в неправильном определении прав. Главное — правильно определить неполадку и исправить её. Благо, это не самая серьёзная из всех ошибок, хотя она и может доставить пользователю неприятности.

Источник

USB-устройства отображаются только для чтения

Я использую Ubuntu 14.04.

У меня 8 ГБ USB-накопитель FAT32 и жесткий диск FAT32 500 ГБ; оба из них внезапно стали устройствами только для чтения.

Я пытался удалить каталог внутри /media и затем создайте его снова, переименуйте, затем предоставьте этому каталогу полные права. Однако это не сработало.

12 ответов

При подключении USB-ключа к ноутбуку:

Проблема должна быть решена сейчас.

Теперь для вашего жесткого диска, пожалуйста, следуйте ответу на этот вопрос. Речь идет о внешнем жестком диске, но это то же самое для вашего случая.

Я получил ту же ошибку при использовании GParted для установки таблицы разделов и форматирования USB-накопителя. после этого все USB-накопители перешли в режим «только для чтения».

Но под рутом копирование работало нормально.

Проблема исчезла после перезагрузки машины. Поэтому я предполагаю, что эта проблема может возникнуть при использовании GParted.

У меня тоже была эта пробема. Я получил ошибку при копировании на мою флешку, я использую Mint 17.1 cinnamon, ядро ​​3.13.0-43 с файловым менеджером caja.

Когда я посмотрел каталог мультимедиа в терминале ‘dir /media’, я увидел, что макет изменился, обычно вы ожидаете увидеть приводы, перечисленные здесь, но теперь они перечислены под вашим именем пользователя, и знаете что? Это имя пользователя имеет только права ROOT.

Что я сделал, так это набрал

где вы заменяете [username] на ваше имя пользователя, удаляете флешку, ждете, а затем вставляете обратно, проблема решена, теперь я могу написать на нее!

У меня возникла та же проблема в Ubuntu, и ни один из ответов, приведенных здесь, до сих пор не работал для меня. Вот что я попробовал:

Я снова посмотрел на разрешения:

Обратите внимание на + в конце разрешений. Это ново для меня, и я никогда не замечал этого раньше. Это означает, что каталог имеет расширенные разрешения, называемые списком контроля доступа (ACL) (см. Этот связанный вопрос). Я перечислил детали ACL для этого каталога:

Как видите, есть дополнительная запись user: :r-x для моего имени пользователя, который только дает мне доступ на чтение. Я исправил это с помощью простой команды:

Я отсоединил USB-разъем, снова подключил его, и проблема была решена.

Я отформатировал с помощью Gparted. Это уничтожило все данные на диске, и оказалось, что это также решило проблему.

Можете ли вы создать какие-либо файлы в вашей домашней папке? Может быть, ваш графический файловый менеджер застрял, думая, что они только для чтения, если вы пытаетесь в терминале, это работает? Например, работают ли эти команды?:

Если они работают успешно, вы можете написать на HD (sda5).

Если файловая система (fs) имеет ошибки, она может быть смонтирована как ro должны быть сообщения об этом в dmesg & /var/log/syslog тоже. Вот что показывают ваши логи:

dmesg в логе тоже говорят как это исправить: fsck может попытаться исправить ошибки FS, он пытается выбрать правильную программу проверки, или вы можете выбрать один явно с fsck.vfat или же fsck.[other] после нажатия клавиши TAB fsck. должен перечислить варианты.

ПРИМЕЧАНИЕ. Это не гарантирует, что файловая система останется исправленной, она снова может быть повреждена, и может быть невозможно точно знать, почему. Всегда отключайте / извлекайте перед удалением USB-накопителей.

Источник

77649:2000428491

43484: 605269286

Жёсткий же мрёт. Сохраняй нужное и пока fsck сделай (хотя не поможет скорей всего).

77670:1220900727

А что mount | grep ro говорит?
Покажи выхлоп mount

77649:2000428491

none on /proc type proc (rw,noexec,nosuid,nodev) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

77670:1220900727

Кореня то нет. Скорее всего или винт летит, или шлейф глючит.

77649:2000428491

Что это значит? БОльшую часть времени работает же без проблем вообще..

77670:1220900727

И в каком файле лога искать корни, чтобы попытаться рабобраться?

77649:2000428491

В линуксе у файловых систем есть опция: перемонтировать в read-only при возникновении ошибок ввода-вывода. Твоя задача найти причину их возникновения. Возможно, действительно умирает жесткий. А может питания не хватает. Да много причин.

77670:1220900727

[ 27.062172] EXT4-fs (sda7): warning: mounting fs with errors, running e2fsck is recommended
[ 27.247949] EXT4-fs (sda8): warning: maximal mount count reached, running e2fsck is recommended
[ 27.249181] EXT4-fs (sda8): recovery complete
[ 27.249440] EXT4-fs (sda8): mounted filesystem with ordered data mode

Попробуй e2fsck (или что-то другое), только сохрани нужное куда-нибудь.

77649:2000428491

77670:1220900727

Что это значит? БОльшую часть времени работает же без проблем вообще..

Насколько я знаю для нормальной работы должен быть примонтирован корень.
Выхлоп mount должен показать что-то вроде:

/dev/sda1 on / type ext4 (ro,noatime,user_xattr,acl,barrier=1,data=ordered)

Слушай, ты бы не давал вредных советов, а? Ты явный нуб, попридержи желание казаться более квалифицированным, чем ты есть.

77670:1220900727

Фильмы можно удалять)
Проси у знакомых флешки/жеские, в крайнем случае dvd-шка стоит около 1$. Сколько инфы то нужно слить?

77649:2000428491

78802: 33230440

Скажи, какой процент вероятности того, что хард начинает накрываться?

Не буду притендовать на инстину, но у меня лично переход в ro шел только из за ошибок чтения, и винт после них был уже ОЧЕНЬ дохлый.

Хотя мало ли по какой причине оно может происходить, как выше замечено ещё шлейф может отходить.

Вообще желательно хотя бы основное все сбекапить, а потом прогнать винт низкоуровневой системой проверки типа Victoria.
Если винту ещё не совсем кирдык (считай блоков не читаемых мало), то она может замедлить процесс смерти ФС на месяц другой.

78802: 33230440

Ну и если скидываь некуда, то заливай на гугл/яндекс/дропбокс в шифрованном виде.

77649:2000428491

На ноуте шлейфа то вроде нету.

а потом прогнать винт низкоуровневой системой проверки типа Victoria.

Смешно. Сервометки уж полтора десятилетия (если не все два) как на заводе ставят и изменить это нельзя. Но нет, «специалисты» всё ещё «рекоммендуют».

Источник

Файловая система доступна только для чтения

Внезапно в ответ на любую команду получаем:

Содержание

Важно [ править ]

Диагностика [ править ]

Проверяем состояние жёсткого диска.
В командной строке (в окне терминала) запускаем с правами суперпользователя:

Примечание [ править ]

Исправление [ править ]

Поиск сбойного блока [ править ]

Посмотрите сообщение о прогнозируемом времени выполнения:
Please wait … minutes for test to complete.
Test will complete after …
Подождите это время и выполните команду

Команда выдаст таблицу. В верхней строчке в столбце «Status» написано «Completed: read failure», в столбце «LBA_of_first_error» написано число — это адрес сбойного блока (сектора), запомните его.

После некоторой задержки (стандартно 70 секунд) команда выдаст ошибку и сообщение.

Отбраковка сбойного блока [ править ]

Внимание! Следующая команда перезаписывает нулями весь сектор, но он и так не читается, главное не ошибиться с сектором и с диском

Должен выдать пачку нулей и не должно быть задержки и ошибки

После этого снова проверяем состояние диска

Если результат «GOOD» — все хорошо

Если же будет «BAD» — нужно смотреть:

Поиск повреждённого файла [ править ]

Используйте программу DMDE — в режиме просмотра физического диска найдите восстановленный сектор и программа покажет, к какому файлу он относится. Затем замените файл из резервной копии. (В случае, если нет резервной копии и это программа или библиотека, найдите пакет, которому принадлежит файл и установите пакет заново.)

После всех манипуляций имеет смысл проверить файловую систему командой fsck на отмонтированной ФС.

Примечания [ править ]

Ненулевые Reallocated_Sector_Ct и Reallocated_Event_Count свидетельствуют о физических сбоях, такой диск лучше заменить.

Offline_Uncorrectable — блоки, ошибки на которых контроллер диска не смог исправить.

Таймауты SCT ERC контроллера диска задают время задержек, при которых блок будет помечен сбойным:

Приложение [ править ]

Скрипт для проверки состояния всех дисков. Требует smartctl и awk

Источник

The title might not be as descriptive as I would like it to be but couldn’t come up with a better one.

My server’s file system went into Read-only. And I don’t understand why it does so and how to solve it.

I can SSH into the server and when trying to start apache2 for example I get the following :

username@srv1:~$ sudo service apache2 start
[sudo] password for username:
sudo: unable to open /var/lib/sudo/username/1: Read-only file system
 * Starting web server apache2                                                                                                                                                                                                               (30)Read-only file system: apache2: could not open error log file /var/log/apache2/error.log.
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.

When I try restarting the server I get :

username@srv1:~$ sudo shutdown -r now
[sudo] password for username:
sudo: unable to open /var/lib/sudo/username/1: Read-only file system

Once I restart it manually it just start up without any warning or message saying something is wrong.

I hope somebody could point me into the right direction to resolve this issue.

Pro Backup's user avatar

Pro Backup

3,1503 gold badges24 silver badges33 bronze badges

asked Oct 7, 2012 at 15:41

John's user avatar

6

The filesystem will usually go into read-only while the system is running if there is a filesystem consistency issue. This is specified in fstab as errors=remount-ro and will occur when a FS access fails or an emergency read-only remount is requested via Alt+SysRq+U. You can run:

sudo fsck -Af -M

to force a check of all filesystems. As one of the other answers states, looking at dmesg is also very helpful.

Edit: Don’t forget the -M on the command-line.

NOTE: As mentioned by Bibhas in his answer: If fsck gets stuck after its version banner:

$ sudo fsck -Af -M
fsck from util-linux 2.20.1

you may want to try using the EXT4-specific fsck

$ sudo fsck.ext4 -f /dev/sda1

Provided the partition in question /dev/sda1 was an ext4 filesystem.

answered Oct 7, 2012 at 15:58

nanofarad's user avatar

nanofaradnanofarad

20.6k12 gold badges65 silver badges91 bronze badges

20

The answer by hexafraction didn’t work for me. Every time I tried executing sudo fsck -Af -M it just showed

$ sudo fsck -Af -M
fsck from util-linux 2.20.1

and nothing else. No error or anything. For me, booting into a live disc and executing this worked —

sudo fsck.ext4 -f /dev/sda1

Provided the partition in question /dev/sda1 was an ext4 filesystem.

notpeter's user avatar

notpeter

1,3841 gold badge8 silver badges9 bronze badges

answered Feb 17, 2014 at 15:44

Bibhas's user avatar

BibhasBibhas

9967 silver badges16 bronze badges

5

Here is the command that solved my problem :

mount -o remount /

better than a reboot or sudo fsck -Af

answered Jan 30, 2013 at 16:23

Sulliwane's user avatar

SulliwaneSulliwane

2,0855 gold badges26 silver badges38 bronze badges

8

If you want to force your root filesystem to remount as rw, you can do the following.

mount -o remount,rw /

answered Jun 1, 2015 at 5:07

johnboiles's user avatar

johnboilesjohnboiles

4494 silver badges3 bronze badges

5

Try running dmesg | grep "EXT4-fs error" to see if you have any issues related to the filesystem / journaling system itself. I would recommend you to restart your system, then. Also, sudo fsck -Af answer by ObsessiveSSOℲ won’t hurt.

answered Jun 24, 2013 at 18:17

thiagowfx's user avatar

thiagowfxthiagowfx

7955 silver badges9 bronze badges

Note that sometimes this can be caused by the computer forgetting the system time — disk check fails because the dates in the journal are in THE FUTURE!

Setting the BIOS time (and checking the BIOS battery) fixed this problem for me, without having to do any disk recovery.

answered Feb 23, 2016 at 2:15

Tony Cook's user avatar

Tony CookTony Cook

1211 silver badge3 bronze badges

2

(Deleted previous answer)

Edit: The main problem was on the windows side. After updating my Windows 10, the ‘quick start’ option automatically got enabled. On disabling that option again, and then again re-starting the machine, the problem went away. Windows 10 gave me heavy headache for days :(

The ‘quick start’ option can be found in ‘power options’ in the control panel. Disable that!!! :)

answered Dec 23, 2017 at 8:18

sarthakgupta072's user avatar

3

If you’re dual booting your machine with Ubuntu and Windows together and this issue occurs,it’s because Windows changes the filesystem,in that case this might do the trick.
Try disabling fast startup

Control Panel > Hardware and Sounds > Power Options > (in the left) Choose what closing the lid does > Change settings that are currently unavailable > Untick ‘Turn on fast startup’

Now booting into Ubuntu will solve the issue. Hope this helps!

answered Apr 25, 2018 at 8:03

Maulik Pipaliya Joyy's user avatar

0

If you have the graphical user interface go to the disk application, select the drive with the issue, click on the gears icon and choose the option Repair Filesystem. In less than a second the problem is fixed.

enter image description here

answered Aug 24, 2021 at 9:53

diegosasw's user avatar

diegosaswdiegosasw

1912 silver badges6 bronze badges

1

If you dual boot ubuntu alongside windows 10 it’s probably windows 10’s fast start-up that’s holding onto your filesystem , it doesnt unmount your hard disks properly.
to fix this you need to boot into windows 10

  1. Start > Power Settings
  2. click on Additional power setting on the right
  3. click on choose what thepower buttons do on the left
  4. clock on change settings that are currently unavailable
  5. unmark turn on fast-startup
  6. save changes
    and then reboot into ubuntu everything will work fine!

answered Oct 14, 2020 at 16:22

Alya Gomaa's user avatar

Alya GomaaAlya Gomaa

611 silver badge7 bronze badges

1

Usually linux puts your filesystems in read only when errors occur, especially errors with the disk or the filesystem itself, errors like a wrong journal entry for example.

You better check your dmesg for disk related errors.

Google is full of discussion about this and you can pick the ones that is closer to your configuration, but a look at dmesg is usually enough.

answered Oct 7, 2012 at 15:58

axis's user avatar

axisaxis

2192 silver badges4 bronze badges

2

For me,Rebooting a system solving this issue

sudo reboot

as he mentioned about it.

Remember

as System Administrator rebooting should be the latest Solution

answered Mar 14, 2017 at 18:09

Zaman Oof's user avatar

Zaman OofZaman Oof

2091 silver badge7 bronze badges

2

If you were in situations that can not use live disc, e.g. you are remotely ssh into your system, you can still using the command that @Bibhas had answered:

sudo fsck.ext4 -f /current/filesystem/mount/point

It will prompt for fixing your filesystem error. You also need to reboot your system remotely.

answered Sep 9, 2018 at 5:14

allenyllee's user avatar

1

In my case it was down to RAID 1 stabilizing after the initial installation. I have /boot and / on s/w RAID1. Having left the system overnight and rebooted, everything is working fine.
Richard

answered Dec 8, 2015 at 11:51

Richard Moore's user avatar

1

It looks like some mounted files have got corrupted, and as a result, the kernel has set the file system to RO to prevent further damage. To find which file system is corrupted, we could run:

cat /proc/mounts | grep -i ro

The output would be similar to the below:

proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
/dev/sda1 / ext4 ro,relatime,data=ordered 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0

One of the solutions for this issue could be to remount the corrupted file system.

answered Jul 22, 2020 at 18:50

Binita Bharati's user avatar

1

I have had this problem on my computer for over 1 year and tried everything to solve the problem. Suddenly Linux goes into read-only mode. If you are editing something you are unable to save and have to execute fsck command and reset the computer. The computer is also very slow and freezing all the time. I removed the dual boot and left only Ubuntu, upgraded Ubuntu from version 18.04 LTS to version 20.04 LTS, and it didn’t work. What was crucial to solving the problem is the use of the dmesg command. The experience didn’t work out for me, just this command. The function of this command is to monitor the computer.

In my case, the problem was related to the SSD incompatibility with Ubuntu. I used HDD and after I switched to SSD the problem came up. The problem was solved by updating the SSD firmware, which was only possible by partitioned Windowns, because Kingston does not have the program to update firmware through Linux. I also installed the dual boot Windowns and Linux, first installing Windows over the entire SSD, then deallocating space through Windowns and installing Ubuntu, but it is very unlikely that this was the solution to the problem.

answered Nov 9, 2020 at 18:01

Denis da Mata's user avatar

1

Check if you have any faulty hardware.I got this error due to a hardisk loosening. Ran mount -o remount,rw / and it worked fine.

answered Jun 15, 2017 at 14:04

Mwongera808's user avatar

I am using the 18.04 LTS release and what I did was, first I unmounted my damaged drives then I went into “Disks” app by seaching in the dash. From there I selected the drive which was damaged. Make sure it is unmounted else it won’t work. In the options menu (the little gear shape), and clicked on “repair file system”. Boom! Worked like a charm.

answered Jun 2, 2018 at 12:07

Cdadgy71's user avatar

It’s misconfigured boot settings (try mounting / as ext2) not drive or partition physical error.

dmesg | grep "error" gave me:

ext3-fs (sda2): error: couldn't mount because of unsupported optional features (240) 
ext2-fs (sda1): error: couldn't mount because of unsupported optional features (240) 
ext4-fs (sda2): mounted file system with ordered data mode: opts: (null)

It mounted / as read only due to the fstab error=mount-ro directive.

Martin Thornton's user avatar

answered Aug 21, 2016 at 6:22

misiagogo's user avatar

Понравилась статья? Поделить с друзьями:
  • Как найти направление антенны
  • Как найти нужного работника
  • Кризис что это за ошибка как исправить
  • Как составить план для квн
  • Смотреть бесплатно как найти родственников