External hard drive with changed access after update

Hello, after one of the updates, maybe a month ago, it happened that the external hard disk that I use for backing up documents is now mounted only in “read only mode”.
I am looking for a solution to restore the previous state of the system (mount the disk, synchronize, detach the disk)
I found a temporary solution but it creates other complications
Has anyone encountered this problem?

@nstst perhaps the filesystem in question is now on the blacklist which was updated recently? Care to share the filesystem in use? This is the list here and what you can do to re-activate https://en.opensuse.org/SDB:FilesystemBlacklisting if it is there…

This is the WD Elements 25A2-1TB, and is ext4 fs.
Maybe i’m wrong about “read only”- because the disk is being mounted, I can see all the files but I can’t open, copy, delete or write new file. And the problem is only in this PC, in raspberry pi 4, no problem

Wel, look with

mount

which mount options are used. Then you can see if ro is there or not.

I never encountered this problem. And I have a permanent solution which doesn’t create other complications.:wink:

1 Like
/dev/sdd1 on /run/media/niki/Elements type ext4 (ro,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)

The device is (re-)mounted read-only. It may be due to errors (errors=remount-ro). Post output of dmesg after your external drive has been connected.

1 Like

And/Or umount and then again mount by command and see what messages appear.

[34658.753677] usb-storage 4-2:1.0: USB Mass Storage device detected
[34658.753829] scsi host9: usb-storage 4-2:1.0
[34659.757030] scsi 9:0:0:0: Direct-Access     WD       Elements 25A2    1021 PQ: 0 ANSI: 6
[34659.757243] sd 9:0:0:0: Attached scsi generic sg4 type 0
[34659.758275] sd 9:0:0:0: [sdd] Spinning up disk...
[34660.769070] ....ready
[34663.809309] sd 9:0:0:0: [sdd] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)
[34663.809591] sd 9:0:0:0: [sdd] Write Protect is off
[34663.809592] sd 9:0:0:0: [sdd] Mode Sense: 47 00 10 08
[34663.809869] sd 9:0:0:0: [sdd] No Caching mode page found
[34663.809870] sd 9:0:0:0: [sdd] Assuming drive cache: write through
[34663.912120]  sdd: sdd1
[34663.912240] sd 9:0:0:0: [sdd] Attached SCSI disk
[34666.694922] EXT4-fs warning (device sdd1): ext4_clear_journal_err:6292: Filesystem error recorded from previous mount: IO failure
[34666.695092] EXT4-fs warning (device sdd1): ext4_clear_journal_err:6300: Marked fs in need of filesystem check.
[34666.696116] EXT4-fs (sdd1): warning: mounting fs with errors, running e2fsck is recommended
[34666.700795] EXT4-fs (sdd1): recovery complete
[34666.700801] EXT4-fs (sdd1): mounted filesystem f7ebdbf5-63b8-48cd-b838-0a206ab48737 r/w with ordered data mode. Quota mode: none.
[34668.117707] EXT4-fs error (device sdd1): ext4_lookup:1857: inode #40632322: comm kioslave5: deleted inode referenced: 40632335
[34668.117726] Aborting journal on device sdd1-8.
[34668.122775] EXT4-fs (sdd1): Remounting filesystem read-only

Well, you have read it yourself I assume. You should run a filesystem check. Unmount the file system and then

e2fsck /dev/sdd1

See what comes out. When in doubt about how to interpret what the messages or questions are, interrupt it and ask here copy/pasting all.

1 Like
niki@localhost:~> sudo e2fsck /dev/sdd1
e2fsck 1.47.0 (5-Feb-2023)
Elements: recovering journal
Elements contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 32517188: 130153997
Multiply-claimed block(s) in inode 32523045: 130153997
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 2 inodes containing multiply-claimed blocks.)

File ... (inode #32517188, mod time Sat Oct  7 22:09:29 2023) 
  has 1 multiply-claimed block(s), shared with 1 file(s):

Elements: ***** FILE SYSTEM WAS MODIFIED *****
Elements: 48454/61046784 files (1.5% non-contiguous), 112842296/244182016 blocks

Thanks everyone for your help, I’ve known some of you for about 15 years from the forum.Unfortunately, I lost my account some time ago…You are always wonderful

That is nice, but is the file system repaired now? Does it mount normally?

1 Like

YES

[37851.308772] sd 9:0:0:0: [sdd] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)
[37851.309081] sd 9:0:0:0: [sdd] Write Protect is off
[37851.309085] sd 9:0:0:0: [sdd] Mode Sense: 47 00 10 08
[37851.309390] sd 9:0:0:0: [sdd] No Caching mode page found
[37851.309394] sd 9:0:0:0: [sdd] Assuming drive cache: write through
[37851.322802]  sdd: sdd1
[37851.322901] sd 9:0:0:0: [sdd] Attached SCSI disk
[37854.437587] EXT4-fs (sdd1): mounted filesystem f7ebdbf5-63b8-48cd-b838-0a206ab48737 r/w with ordered data mode. Quota mode: none.

I checked everything is fine

Congratulations.

1 Like

I experienced similar problems with ext4 in the past. These were gone when switching existing storage drives to btrfs.

They tried to improve ext4 for a good reason: Ext4 Metadata Checksums - Ext4

However btrfs shines with robustness and ease of administration. Thus I stopped creating new ext4 filesystems.

However, ext4 shines with robustness and ease of administration too. Users and administrators are therefore free to choose the file system that best suits their needs and usecase.