Cannot mount or format external SSD

[Mæstro]

A few days ago, I purchased a 16 TB external SSD for the purpose of keeping system backups. After some delays due to personal matters, I could at last connect the new drive to my computer, hoping to take backups. When I first connected it, I could hear the sound Cinnamon plays when a USB drive is connected, but no new drive appeared listed in /media, nor did the Devices (German Geräte; keep in mind my system language is German, and all English translations of computer messages are my own) dropdown on the left in Nemo appear. The device’s presence is detected by lsusb (as Bus 003 Device 005: ID 048d:1234 Integrated Technology Express, Inc.) and, if I open My Computer (Rechner, or computer:///, a USB drive of indefinite size called FS SSD appears as a directory, as well as my computer’s own hard and optical drives. If I click on it or try to mount (einhängen) it in Nemo, I am told it is impossible (Einhängen des Ortes nicht möglich / Datei konnte nicht eingehängt werden). Nemo Under Properties (Eigenschaften), all values but the name are unknown.

Reasoning that the drive might simply need formatting, I opened GParted, which could tell more information about the drive. I was greeted the following error message in a mixture of German and English: ‘Libparted-Fehler: Eingabe-/Ausgabefehler during read on /dev/sdb’, with choices to try again (wiederholen), cancel (abbrechen) the operation or ignore (ignorieren) the message. Repeating the operation returned the same error, while ignoring would say (in English) ‘the backup GPT table is corrupt, but the primary appears OK, so that will be used.’ It then correctly detected the SSD as 16 TB in size, with two partitions: a Microsoft reserved partition of 150 MB, and the rest in a Microsoft basic data partition. Consulting online, I deleted them both in Gparted and created a new partition table (msdos, the default).

Formatting the drive in Gparted is where I now run aground. If I try to format it as EXT4, I receive the following sequence, which has been copied from the save details (Details speichern) page:

Code: Select all

GParted 0.32.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2
/dev/sdb1 als ext4 formatieren  00:01:17    ( FEHLER )
     	
/dev/sdb1 kalibrieren  00:00:00    ( ERFOLG )
     	
Pfad: /dev/sdb1 (Partition)
Anfang: 256
Ende: 4095999999
Größe: 4095999744 (15.26 TiB)
Alte Dateisystem-Signaturen auf /dev/sdb1 löschen  00:00:02    ( ERFOLG )
     	
write 512.00 KiB of zeros at byte offset 0  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 67108864  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 274877906944  00:00:00    ( ERFOLG )
write 512.00 KiB of zeros at byte offset 16777214427136  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 16777214885888  00:00:00    ( ERFOLG )
write 8.00 KiB of zeros at byte offset 16777214943232  00:00:00    ( ERFOLG )
Betriebssystem-Zwischenspeicher von /dev/sdb leeren  00:00:02    ( ERFOLG )
     	
libparted-Benachrichtigungen    ( INFO )
     	
Eingabe-/Ausgabefehler during write on /dev/sdb
Partitionstyp auf /dev/sdb1 festlegen  00:00:00    ( ERFOLG )
     	
Neue Partitionstyp: ext4
Neues ext4-Dateisystem erzeugen  00:01:15    ( FEHLER )
     	
mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb1'  00:01:15    ( FEHLER )
     	
64-bit filesystem support is not enabled. The larger fields afforded by this feature enable full-strength checksumming. Pass -O 64bit to rectify.
Creating filesystem with 4095999744 4k blocks and 512000000 inodes
Filesystem UUID: 8c991d6c-0d80-4c74-88cb-fa7fc7ff9300
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000, 3855122432

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: 6562/125000
mke2fs 1.44.5 (15-Dec-2018)
mkfs.ext4: Eingabe-/Ausgabefehler while writing out and closing file system

Because I have tried a few times now, I can say that it manages to write a few thousand superblocks (as low as 1200, but no more than 6562) before failing. Those it managed were achieved within a few seconds, but the operation timed out and failed after 1′15″. When trying to format it, one receives the same error message with three choices, ‘Eingabe /Ausgabefehler during read on /dev/sdb’, where behaviour is identical whether trying again or ignoring the error message. In Gparted now, unlike when I began, I am given instead the warning (not error) message ‘Error fsyncing/closing /dev/sdb1: Eingabe-/Ausgabefehler’. For all the mention of input/output errors, the cable, port and socket are all new and working well with other devices.

Attempting to format as NTFS gives immediately the original error message with its three choices, where trying again or ignoring fails immediately with input/output errors writing to the drive, such that Gparted cannot create a root directory on the SSD. Of course, FAT32 formatting is impossible, given the size of the drive. Despite everything, at any point throughout this, if I go to My Computer, I can select to remove the device safely, whereupon Cinnamon makes the confirming noise and the drive disappears from that directory. Upon request, I can try to provide more information.

Because the hard drive is new and can be detected, I strongly doubt that the problem is due to defective hardware, as online searching has revealed tends to cause such input/output problems. After installing smartctl, which I could read online is useful for testing hard drive integrity in any case, I could get the following:

Code: Select all

maestro@ayaka:~$ smartctl /dev/sdb -i
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-27-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/sdb: Unknown USB bridge [0x048d:0x1234 (0x100)]
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

maestro@ayaka:~$ 

From smartctl’s manual, I do not know which of the many possibilities listed in the help output would actually apply.

Because of a variety of technical and personal problems which would distract from this post’s purpose, I have not been able to make complete system backups in over a year, which is quite embarrassing. Although my situation now, unlike before, could permit me to adopt Proton’s remote storage for preserving my personal files, if the upload rate has improved since I tried it a few years ago, I would rather make on-site backups if at all possible, and I would rather not let this issue force my VPN choice, a matter i am still deliberating. How may I format and mount this SSD to make it usable for my personal backups?

[Moonchild]

Sounds to me like your external drive chipset needs specific drivers which aren't included in Linux.

[UCyborg]

Maybe you should have chosen gpt instead of msdos (since you already nuked partition table, personally, I would have left it as GPT and just check partitions are in order). Supposedly MBR (msdos) on > 2 TB disk is poorly supported scenario.

Edit: Maybe there is something on a lower level. I actually have Debian 10 on a virtual machine and when it comes to external WD's 5 TB disk that came with 1 partition formatted as NTFS on GPT table, GParted selects gpt on the dropdown by default if you try to go and make a new partition table.

[Mæstro]

I ended up experimenting with repartitioning with GPT afterwards on my own, before reading your post, but i just ended up getting the same error messages which I had got before replacing the factory-installed ones. Moonchild is right. Since I still can, I will simply return this SSD and find another one which is compatible with Linux. I will bear in mind your caution about SSD larger than 2 TB.

[UCyborg]

Oh, well, I wouldn't draw conclusions from the old Debian. I'm not sure on the specifics of > 2 TB since apparently a bunch of things changed throughout time that caused 2 TB being written across the internet as a hard limit when it comes to MBR, although it may not be entirely accurate due to other factors.

[UCyborg]

Regardless, it's just a SSD. How come something as banal need special handling?

[Mæstro]

This is the first time I have experienced an SSD failing like that in Linux. Three years ago, I used a 2 TB external SSD with Debian 10 without complications. In any case, I could find a cheap, 128 GB USB drive at the hypermarket. It runs normally in Linux and hence should suffice for making my personal backups, if I might not be able to keep multiple versions of my home directory on file as hoped. (I would have got 256 GB, which would be enough, but the shop was sold out.)

[Bilbo47]

Suggest check https://grc.com/ValiDrive.htm in case the drive capacity is not actually 16TB.

[Drugwash]

A few days ago, I purchased a 16 TB external SSD [...] Formatting the drive in Gparted is where I now run aground.
/dev/sdb: Unknown USB bridge [0x048d:0x1234 (0x100)]

That particular VID&PID combination has been reported by people as being defective/fake drives. Dunno how accurate this is. See here for a short discussion.
Allegedly the manufacturer of the drive's controller is ITE Taiwan according to this site.
Your system may well lack the proper driver for that controller but it may also be that it's just not in smartctl's database. Try running update-smart-drivedb.
You should try and update your gparted and libparted too, might help.

If nothing helps and you're willing to forfeit the warranty for the drive - if any - you could disassemble it (remove the actual drive from its enclosure), buy a separate USB drive dock that is known to be detected by existing Linux drivers, mount the drive in the dock and connect the dock to your computer.

Personally I bought a couple of 12TB regular (not SSD) Seagate drives, a couple USB docks (Reagle would be the manufacturer, exactly as the one in the picture), mounted each drive in a dock - although the dock supports two drives - and had no problems detecting and formatting them in Linux Mint 19.2 Cinnamon (libparted 3.6, gparted 1.8.0 - from Rob Savoury's backports PPA). See one of the docks in the picture below.

Checking with lsusb the two docks appear as follows:
Bus 002 Device 008: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 010: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
(as you can see the VID & PID are different than yours)

20250106_141751resize.jpg

[Mæstro]

Since I think the fact might have been lost, I have already returned the ‘16 TB’ drive to the vendor. Knowing it was most likely fraudulent is a welcome explanation in any case for why this drive disagreed with my system. Thank you both for bringing that possibility to my attention!

[Drugwash]

Well, at least you haven't lost your money.
If you ever need external storage again you may want to choose the dock option, and first check the VID & PID for compatibility with your system.

[Octopuss]

Holy crap, 16TB SSD? Wow! I must have been living under a rock for years. I had no idea such capacities existed in let's say, "desktop environment".