mount: wrong fs type, bad option, bad superblock
I added a new hard drive (/dev/sdb
) to Ubuntu Server 16, ran parted /dev/sdb mklabel gpt
and sudo parted /dev/sdb mkpart primary ext4 0G 1074GB
. All went fine. Then I tried to mount the drive
mkdir /mnt/storage2
mount /dev/sdb1 /mnt/storage2
It resulted in
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.
I tried mount -t ext4 /dev/sdb1 /mnt/storage2
with identical outcome. I’ve done this stuff many times before and have never ran into anything like this. I’ve already read this mount: wrong fs type, bad option, bad superblock on /dev/sdb on CentOS 6.0 to no avail.
fdisk output regarding the drive
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
WARNING: This will wipe out your drive!
You still need to create a (new) file system (aka "format the partition").
Double-check that you really want to overwrite the current content of the specified partition! Replace XY
accordingly, but double check that you are specifying the correct partition, e.g., sda2
, sdb1
:
mkfs.ext4 /dev/sdXY
parted
/ mkpart
does not create a file system.
The Parted User’s Manual shows:
2.4.5 mkpart
Command:
mkpart [part-type fs-type name] start end
Creates a new partition,
without creating a new file system on that partition.
[Emphasis added.]
I had this problem with /dev/sda on Ubuntu 16.04 I solved it by booting into a live usb and doing the following:
To see your disks use lsblk
If you can see your drive thats good, run fdisk -l
to see if the system can use it.
Run this command to attempt to repair bad superblocks on the drive.
fsck /dev/sda1
(replace /dev/sda1 with the drive you want to fix).
When it asks to repair blocks select yes by pressing ‘y‘
Allow fsck to repair all bad blocks.
Then I was able to mount the device using
sudo mount /dev/sda /media/ubuntu
This solved it for me.
# create mount dir
sudo mkdir /hdd6T
# new file system
sudo mkfs.ext4 /dev/sdc
# mount drive
sudo mount /dev/sdc /hdd6T/
# change ownership to specified user
sudo chown your-user /hdd6T/
I have a different process for this that replaced the bad superblock with one of the alternatives. FSCK can be a “lossy” process because FSCK may want to remove too much data or to remove data from a sensitive location (e.g. data directory for a data base) so there are times when I don’t want to use it or it doesn’t work.
You can sudo yourself silly or just become root for the process. Just remember that when you are root, Linux assumes that you know what you’re doing when you issue commands. If so directed, it will speedily delivery Mr. Bullet to Mr. Foot. Like many other things, with great power comes great responsibility. That concludes my warning on running your system as root.
sudo -s
fdisk -l
Figure out which device – assuming /dev/sdc1 for this example along with EXT4 as its the most common for this explanation.
fsck -N /dev/sdc1
Your device and your file system (ZFS, UFS, XFS, etc.) may vary so know what you have first. Do not assume it’s EXT4. Ignoring this step can cause you problems later if it’s NOT an EXT4 file system.
fsck.ext4 -v /dev/sdc1
Get your error message which says the superblock is bad. You don’t want to do this if your superblock is OK.
mke2fs -n /dev/sdc1
This will output the alternate superblocks stored on your partition.
*Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208*
Pick an alternate superblock – keep in mind that the first one is the default and its bad so let’s not use that one. You will also want to pick one from the list you get from your partition. Do not use the example. Your superblocks may be stored elsewhere.
e2fsck -b 98304 /dev/sdc1
Reboot and see if this worked. If not try the next superblock on the list. I’ve had to go the third or fourth one a couple of times.
e2fsck -b 163840 /dev/sdc1
Now try the command to validate the disk again. See if you get the same messabout about bad superblocks.
fsck.ext4 -v /dev/sdc1
Keep trying until you either run out of superblocks or it works. If you run out, you likely have bigger issues and I hope you have good backups. You can try running FSCK at that point.
In my case, the solution was install nfs-utils
on the client side.
CentOS/Red Hat:
yum install nfs-utils
Ubuntu/Debian:
apt update
apt install nfs-kernel-server
I know this is an old question but in case this helps anyone that stumbles across this.
I was attempting to connect and NFS mount but was failing and getting the same error as OP.
After installing the dependencies I was good to go:
sudo apt install nfs-common
For me, there was some mysterious file causing this issue.
I had to clear the directory using the following command:
sudo mkfs -t ext3 /dev/sdf
Warning: this might delete files you have saved. So you can run ls
to make sure you don’t lose important saved files and backup these files before execution.
If you are trying to mount image file in any folder present in /home in ubuntu then try these Commands:
Generalized :
>>mkdir <name of your directory>
>>sudo mount -o ro <name of image file with extension> <name of your directory>/
Specified: name of your directory = system , name of image file with extension = system.img
>>mkdir system
>>sudo mount -o ro system.img system/
I had to install ntfs-3g as it was an NTFS formatted partition and Linux kernel versions before 5.15 didn’t support ntfs out of the box. NTFS-3G is a FUSE filesystem (Filesystem in Userspace)
For me, the message appeared in dolphin. With installing ntfs-3g, dolphin can mount it properly.
I got the same error on boot and it was due to wrong filesystem entry on /etc/fstab
.
The entry was
/dev/mapper/vgso-lvso /so xfs defaults 0 0
and it should be ext4 mounted
/dev/mapper/vgso-lvso /so ext4 defaults 0 0
for me the problem was that the mount command contained options (umask, uid) which was not accepted (probably due to the device has ext4 file system)
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.
After removing the options, it worked
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
After mount the permissions or ownership can be set to able to have write permissions for non root users.
sudo chown -R pi:pi /media/ssd
In my case I wasn’t paying attention, and was trying to mount /dev/sda /mnt
instead of mount /dev/sda1 /mnt
. Be careful out there!
My HD shows up in Gparted as unallocated
but it isn’t showing up in File (same thing in windows Disk management and File explorer)
I used testdisk to recreate the partition table and I was able to recover my HD and all the data without formatting it.
- In the terminal enter
testdisk
- Then choose create a log
- Then select the HD and choose the partition type (most probably Intel)
- Then select Analyse
- If you only have 1 partition in your HD, then just mark the one that shows up as
Bootable partition
(with the left-right arrow). Then press "Enter" to continue - If you had more, you should now do a "deeper search", otherwise choose
Write
Unplug your HD and plug it again (this is what they mean, in this case, by "reboot")
in my case changing sata cable powering both drives and restart seems to fix the problem. however I was unable to mount them on the same old point so changing them fixed for me. then I manually remove the old mount points from mnt directory 🙂
Unbelievable. I see this come up All the time. I can manually mount with the mount command no problem. When I try to mount -a
I get the same bad fs type error. I looked at the /etc/fstab
carefully and saw I spelled default
not defaults
. It is the spelling that gets me.
To get a usable volume out of a new disk, you have to carry the following steps:
- Create a partition table on the disk, aka disklabel. there are two possible formats,
msdos
orgpt
. - Create as many partitions as desired from the disk space. each partition is essentially defined by a begin/end addresses and partition type. The filesystem type is not definitely not a partition attribute, although some commands like
parted
may use it to set the partition type. Each partition will be considered as a block device on the system and accessible as a block file like/dev/sdb1
. - Create a filesystem on the desired partition, which actually means organizing the partition raw space in a way suitable to store files/folders/links, etc., i.e. the file hierarchy. The filesystem attributes are stored in the superblock, which is generally one disk block at the very beginning in the partition space.
Given this short introduction, you’ll notice that you still have to go through the third step. You may use for this mkfs.ext4 /dev/sdb1
.