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

Я добавил новый жесткий диск (/dev/sdb) на Ubuntu Server 16, выполнил parted /dev/sdb mklabel gpt и sudo parted /dev/sdb mkpart primary ext4 0G 1074GB. Все прошло хорошо. Затем я попытался смонтировать диск

mkdir /mnt/storage2
mount /dev/sdb1 /mnt/storage2

Это привело к следующему

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Я попробовал mount -t ext4 /dev/sdb1 /mnt/storage2 с аналогичным результатом. Я делал это много раз раньше и никогда не сталкивался с чем-то подобным. Я уже читал это mount: wrong fs type, bad option, bad superblock on /dev/sdb on CentOS 6.0, но безуспешно.

Вывод fdisk относительно диска

Disk /dev/sdb: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0E136427-03AF-48E2-B56B-A467E991629F

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 2097149951 2097147904 1000G Linux filesystem 

ВНИМАНИЕ: Это приведет к удалению данных на вашем диске!

Вам все равно нужно создать (новую) файловую систему (то есть “отформатировать раздел”). 

Дважды проверьте, что вы действительно хотите перезаписать текущее содержимое указанного раздела! Замените XY соответствующим образом, но дважды проверьте, что вы указываете правильный раздел, например, sda2, sdb1:

mkfs.ext4 /dev/sdXY

parted / mkpart не создает файловую систему. 
Пользовательская документация Parted показывает:

2.4.5 mkpart

Команда: mkpart [part-type fs-type name] start end

Создает новый раздел,
не создавая новой файловой системы на этом разделе.

    ^{[Выделение добавлено.]}

У меня была эта проблема с /dev/sda на Ubuntu 16.04, я решил ее, загрузившись с live usb и сделав следующее:

Чтобы увидеть ваши диски, используйте lsblk

Если вы видите свой диск, это хорошо, выполните fdisk -l, чтобы проверить, может ли система его использовать.

Запустите эту команду, чтобы попытаться исправить плохие супервизоры на диске.

fsck /dev/sda1 (замените /dev/sda1 на диск, который вы хотите исправить).

Когда он спросит о ремонте блоков, выберите “да”, нажав ‘y‘

Позвоните fsck, чтобы исправить все плохие блоки.

После этого я смог смонтировать устройство, используя

sudo mount /dev/sda /media/ubuntu

Это решило проблему для меня.

В моем случае решением было установить nfs-utils на клиентской стороне.

CentOS/Red Hat:

yum install nfs-utils

Ubuntu/Debian:

apt update
apt install nfs-kernel-server

У меня был другой процесс для этого, который заменил плохой суперблок одним из альтернативных. FSCK может быть “потерянным” процессом, потому что FSCK может захотеть удалить слишком много данных или удалить данные из чувствительного места (например, каталога данных для базы данных), поэтому иногда я не хочу его использовать или он не работает.

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

sudo -s

fdisk -l

Определите какое устройство – предполагая /dev/sdc1 для этого примера вместе с EXT4, так как это наиболее распространено для этого объяснения.

fsck -N /dev/sdc1

Ваше устройство и ваша файловая система (ZFS, UFS, XFS и т.д.) могут отличаться, поэтому сначала узнайте, что у вас есть. Не предполагайте, что это EXT4. Игнорирование этого шага может вызвать проблемы позже, если это не файловая система EXT4.

fsck.ext4 -v /dev/sdc1

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

mke2fs -n /dev/sdc1

Это создаст резервные суперблоки, хранящиеся на вашем разделе.

*Резервные копии суперблоков хранятся на блоках:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208*

Выберите альтернативный суперблок – имейте в виду, что первый является стандартным, и он плохой, так что давайте не будем использовать его. Вы также захотите выбрать один из списка, который вы получили от вашего раздела. Не используйте пример. Ваши суперблоки могут храниться в другом месте.

e2fsck -b 98304 /dev/sdc1

Перезагрузите и посмотрите, сработало ли это. Если нет, попробуйте следующий суперблок из списка. Мне приходилось проходить до третьего или четвертого несколько раз.

e2fsck -b 163840 /dev/sdc1

Теперь попробуйте снова выполнить команду, чтобы проверить диск. Посмотрите, получите ли вы то же сообщение о плохих суперблоках.

fsck.ext4 -v /dev/sdc1

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

Для меня проблема заключалась в том, что команда mount содержала параметры (umask, uid), которые не принимались (возможно, из-за того, что устройство имеет файловую систему ext4)

sudo mount /dev/sda1 /media/ssd -o uid=pi,gid=pi
mount: /media/ssd: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
sudo mount /dev/sda1 /media/ssd -o umask=000
mount: /media/ssd: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

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

sudo mount /dev/sda1 /media/ssd
df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      ext4      220G   61M  208G   1% /media/ssd

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

sudo chown -R pi:pi /media/ssd

Мой жесткий диск отображается в Gparted как неразмеченный, но он не отображается в Файле (то же самое в диспетчере дисков Windows и проводнике файлов)

Я использовал testdisk, чтобы восстановить таблицу разделов, и я смог восстановить мой жесткий диск и все данные без его форматирования.

1. В терминале введите testdisk
2. Затем выберите создать журнал
3. Затем выберите жесткий диск и выберите тип раздела (скорее всего, Intel)
4. Затем выберите Анализ
5. Если у вас только один раздел на жестком диске, просто отметьте тот, который отображается как Загрузочный раздел (с помощью стрелки влево-вправо). Затем нажмите “Enter”, чтобы продолжить
6. Если у вас было больше, вам следует сделать “глубокий поиск”, в противном случае выберите Записать

Выключите жесткий диск и подключите его снова (в данном случае это то, что они имеют в виду под “перезагрузкой”)

Мне пришлось установить ntfs-3g, так как это был раздел с файловой системой NTFS, и версии ядра Linux до 5.15 не поддерживали ntfs из коробки. NTFS-3G – это файловая система FUSE (Файловая система в пространстве пользователя)

Для меня сообщение появилось в dolphin. С установкой ntfs-3g dolphin может правильно смонтировать его.

Если журналы dmesg показывают что-то вроде

[ 4990.686372] ntfs3: sda7: Рекомендуется использовать chkdsk.

[ 4990.734846] ntfs3: sda7: том грязный и флаг “force” не установлен!

Это означает, что на разделе NTFS установлен флаг грязности; драйвер NTFS в Linux монтирует R+W только если он не установлен; RO-монтирование работает независимо от грязности.

Тем не менее, если вы хотите R+W монтирование, это можно исправить с помощью ntfsfix -d, если это возможно:

-d, --clear-dirty
    Очистите флаг грязности тома, если том может быть исправлен и смонтирован. Если опция отсутствует или том не может быть исправлен, флаг грязного тома устанавливается, чтобы запросить проверку тома при следующем монтировании.

Запуск

$ ntfsfix -d /dev/sda7

Монтаж объема... ОК
Обработка $MFT и $MFTMirr завершена успешно.
Проверка альтернативного загрузочного сектора... ОК
Версия NTFS тома 3.1.
Том NTFS /dev/sda7 был обработан успешно.

исправил проблему для меня.

Если это не сработает, следующим шагом будет использование chkdsk на машине с Windows.

Смотрите Почему NTFS имеет грязный признак и почему NTFS3 не может монтировать грязные разделы NTFS? для получения дополнительной информации.

Невероятно. Я вижу это постоянно. Я могу вручную смонтировать с помощью команды mount без особых проблем. Когда я пытаюсь mount -a, я получаю ту же ошибку типа файловой системы. Я внимательно посмотрел на /etc/fstab и заметил, что я написал default не defaults. Это орфография меня подводит.

Чтобы получить работоспособный том с нового диска, необходимо выполнить следующие шаги:

1. Создать таблицу разделов на диске, также известную как дисковая метка. Существуют два возможных формата: msdos или gpt.
2. Создать столько разделов, сколько необходимо из пространства диска. Каждый раздел определяется начальными/конечными адресами и типом раздела. Тип файловой системы не является атрибутом раздела, хотя некоторые команды, такие как parted, могут его использовать для установки типа раздела. Каждый раздел будет рассматриваться как блочное устройство в системе и доступен как блочный файл, например /dev/sdb1.
3. Создать файловую систему на нужном разделе, что фактически означает организацию сырого пространства раздела таким образом, чтобы хранить файлы/папки/ссылки и т.д., т.е. файловую иерархию. Атрибуты файловой системы хранятся в суперблоке, который, как правило, находится в одном дисковом блоке в самом начале пространства раздела.

Учитывая это краткое введение, вы заметите, что вам все равно нужно пройти через третий шаг. Вы можете использовать для этого mkfs.ext4 /dev/sdb1.

Я знаю, что это старый вопрос, но на случай, если это поможет кому-то, кто наткнется на это.

Я пытался подключиться и смонтировать NFS, но у меня ничего не получалось, и я получал ту же ошибку, что и OP.

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

sudo apt install nfs-common

В моем случае я не обращал внимания и пытался mount /dev/sda /mnt, вместо mount /dev/sda1 /mnt. Будьте осторожны!

Если хотите смонтировать диск в Linux Mint, вот как выглядит мой дополнительный диск

Вам просто нужно создать раздел из меню, и большинство сделает это автоматически, а параметры монтирования приходят автоматически, диск монтируется под /media/

Я получил ту же ошибку при загрузке, и это было из-за неправильной записи файловой системы в /etc/fstab.

Запись была

/dev/mapper/vgso-lvso /so xfs defaults 0 0 

и это должно быть смонтировано как ext4

/dev/mapper/vgso-lvso /so ext4 defaults 0 0 

Для меня была какая-то загадочная ошибка, вызывающая эту проблему.

Мне пришлось очистить директорию, используя следующую команду:

sudo mkfs -t ext3 /dev/sdf

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

Если вы пытаетесь смонтировать файл образа в любой папке, находящейся в /home в Ubuntu, попробуйте эти команды:

Общие:

>>mkdir <имя вашей директории>
>>sudo mount -o ro <имя файла образа с расширением> <имя вашей директории>/

Конкретное: имя вашей директории = system, имя файла образа с расширением = system.img

>>mkdir system                                
>>sudo mount -o ro system.img system/

В моем случае смена SATA-кабеля, питания обоих дисков и перезагрузка, кажется, исправила проблему. Тем не менее, я не смог смонтировать их в той же старой точке, поэтому их замена исправила ситуацию для меня. Затем я вручную удалил старые точки монтирования из каталога mnt 🙂

Если это поможет кому-то:
У меня была эта проблема по другой причине. Я пытался смонтировать весь свой диск nvme0n1, который был моей системой двойной загрузки! И поэтому mount жаловался, потому что я пытался смонтировать некоторые разделы Windows (ntfs) на своем liveusb (ext4), что вызывало ошибки, видимые в dmesg.

Решение заключалось в том, чтобы проверить, какой раздел содержал мою установку Linux, с помощью sudo fdisk -l /dev/nvme0n1, а затем смонтировать именно его с помощью sudo mount /dev/nvme0n1p7 /mnt.

В моем случае простая опция “Восстановить файловую систему” из утилиты “Диски” решила проблему.

Для совершенно новых пользователей Linux, метод GUI (на Gnome) выглядит следующим образом –

Откройте утилиту “Диски” -> Выберите ваш диск слева -> Нажмите на значок колеса справа -> Выберите “Восстановить файловую систему”

Убедитесь, что файловая система на разделе соответствует файловой системе в fstab. Везде есть “x”, поэтому мой дислексический мозг перепутал ext4 с xfs, потому что я следил за рецептом, который использовал ext4, но диск, который я заменял, был отформатирован как xfs. (Примеры ниже работают на Rocky 9)

Если вы заменяете диск и /etc/fstab содержит xfs, который выглядит так:

/dev/disk/by-id/nvme-Micron_9300_MTFDHAL15T3TDP_221837870467-part1      /data/rt/0      xfs     defaults        0 0

то отформатируйте новый раздел, используя

sudo mkfs.xfs /dev/disk/by-id/nvme-Micron_9300_MTFDHAL15T3TDP_221837870467-part1

затем

sudo systemctl --daemon-reload
sudo mount -a

Примечание: вы не хотите использовать такие имена, как /dev/nvme1n1p1, поскольку эти номера могут и меняются при каждой перезагрузке, потому что это аппаратная гонка для пронумерования дисков. Используйте команду udevadm info ..., чтобы узнать альтернативные имена /dev/data/by-id/*, которые не изменяются при каждой перезагрузке.

Если нужно, определите раздел с помощью:
lsblk -f
затем

sudo ntfsfix NAME_OF_FAILING_PARTITION

если это все еще не работает
добавьте опцию -d, то есть

sudo ntfsfix -d NAME_OF_FAILING_PARTITION

это сработало для меня на Manjaro с ntfsfix v2022.10.3 (libntfs-3g)