24.04 can't read from external SSD storage

[lads]

I have a few portable SSD storage units around, backing up old projects, photos, etc. Yesterday I installed Ubuntu 24.04 on one of the laptops and it is unable to read from any of the SSD units. They mount fine, and Nemo is able to show the folder structure and contents correctly. However, either trying to open or copying a file/folder always fails with the message: "Input/output error".

(Click here if the image does not show.)

All the other systems I use (e.g. Ubuntu 22.04) are able to read/write to these SSD units without issue. What could be wrong on 24.04?

Thank you for reading.

[#&thj^%]

Whats in "dmesg" anything to help us here?

Mostly caused by a failing drive, (But not here as you show it works with other systems)

The only time I have ever seen cp giving this error was when an iso image was mounted twice, eg: /dev/<Your Mount here> mounted on /mnt AND /dev/loop0 mounted on /mnt too. In this scenario, I think cp gets some recursion it can't handle. For me, unmounting both loop0 and /dev/<your mount>, then running mount -o loop /dev/<your mount> /mnt again fixed it (done by root or sudo user).

But maybe "dmesg" may shed some light.

Or even:

df -hT

[Rubi1200]

Please also show us the output of this command:

lsblk -e 7 -o name,size,type,fstype,mountpoint

[lads]

Thank you for the replies. Following these suggestions the root of the issue could be identified:

$ lsblk -e 7 -o name,size,type,fstype,mountpoint
NAME                                            SIZE TYPE  FSTYPE      MOUNTPOINT
sda                                           465,8G disk
└─sda1                                        465,8G part  crypto_LUKS
  └─luks-1841d2d1-4ce7-46e4-805e-0be262199e7d 465,7G crypt ext4        /media/lads/NOAB
nvme0n1                                       953,9G disk
├─nvme0n1p1                                   856,1G part  ext4        /home
├─nvme0n1p2                                     300M part  vfat        /boot/efi
└─nvme0n1p3                                    97,5G part  ext4        /

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
tmpfs          tmpfs     1,6G  2,7M  1,6G   1% /run
/dev/nvme0n1p3 ext4       96G   12G   80G  13% /
tmpfs          tmpfs     7,7G  181M  7,5G   3% /dev/shm
tmpfs          tmpfs     5,0M   12K  5,0M   1% /run/lock
efivarfs       efivarfs  192K  128K   60K  69% /sys/firmware/efi/efivars
tmpfs          tmpfs     7,7G   52M  7,6G   1% /tmp
/dev/nvme0n1p2 vfat      300M  7,8M  292M   3% /boot/efi
/dev/nvme0n1p1 ext4      842G   36G  764G   5% /home
tmpfs          tmpfs     1,6G  312K  1,6G   1% /run/user/1000
/dev/dm-0      ext4      458G  273G  162G  63% /media/lads/NOAB

$dmesg
[...]
[24234.292510]  sda: sda1
[24234.292923] sd 0:0:0:0: [sda] Attached SCSI disk
[24244.998079] EXT4-fs warning (device dm-0): ext4_clear_journal_err:6291: Filesystem error recorded from previous mount: IO failure
[24245.004901] EXT4-fs warning (device dm-0): ext4_clear_journal_err:6299: Marked fs in need of filesystem check.
[24245.011502] EXT4-fs (dm-0): warning: mounting fs with errors, running e2fsck is recommended
[24245.020974] EXT4-fs (dm-0): recovery complete
[24245.021001] EXT4-fs (dm-0): mounted filesystem 72da4a80-d831-464e-a139-b75eb7a118da r/w with ordered data mode. Quota mode: none.
[24248.020372] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 126: bad block bitmap checksum
[24248.020401] Aborting journal on device dm-0-8.
[24248.031299] EXT4-fs (dm-0): Remounting filesystem read-only
[24266.405485] ------------[ cut here ]------------

And here is the diagnosis from e2fsck:

$ sudo e2fsck -pf /dev/sda
e2fsck: Bad magic number in super-block while trying to open /dev/sda
/dev/sda:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a dos partition table in /dev/sda

I am wary of moving forwards with a repair since this volume is perfectly readable/writable on Ubuntu 22.02. Any advice? If I try a different superblock is there any risk of data loss?

Thank you.

[oldfred]

Your e2fsck if for ext4 (or ext2, ext3) formatted partitions.
You tried to run it on a drive like sda, not a partition like sda1 or nvme0n1p3.
And with LVM you have to mount and use it.

fsck
https://askubuntu.com/questions/1124...disk-with-fsck
fsck on encrypted LUKS
http://serverfault.com/questions/375...encrypted-disk

[HermanAB]

The fact that ALL of them fail in the same way only on THAT computer, is suspicious and points to a common cause. How are the external disks powered? Try a USB hub with a separate PSU to connect to external drives.

[lads]

@oldfred I tried to run e2fsck against the partition, the output is exactly the same as reported above. I also tried to mount the volume beforehand, but that way it refuses to run (as the manual explains).

I ran e2fsck from Ubuntu 22.04 and the results are also the same: "The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem". All the while I can use the volume without issue on that system. Perhaps the tool is not being used correctly?

Back on 24.04, I am now able to use one of the concerned SDD units by mounting manually as described in this post at AskUbuntu. I will later try the other SSD units.

In any event, I would welcome any hints on why the auto-mount is failing. Thanks.