1

I have a LUKS encrypted partition on a second hard drive that I use on my computer. When I turn on my computer, it is encrypted unless I go to it and try to open it, an operation that the system then does on its own because when I did it for the first time I left the password recorded. That is, I click on it and the system mounts it unencrypted for me.

It turns out that for some time now, this operation has been mounting the partition on the HD in question as read-only. It was never like that, it was always mounted with write privileges too. What can I do to solve this problem?

I have the partition password. My operating system is POP OS 22.04.

Another thing: I noticed that there are times when I mount the partition, in the beginning I can, for example, create folders and everything, then a while passes, I can't do it anymore. It's like it went from read-write to read-only.

UPDATE 1:

I used dmesg and found this information:

[   97.995228] EXT4-fs warning (device dm-3): ext4_clear_journal_err:6017: Filesystem error recorded from previous mount: IO failure
[   97.995233] EXT4-fs warning (device dm-3): ext4_clear_journal_err:6019: Marking fs in need of filesystem check.
[   98.027267] EXT4-fs (dm-3): warning: mounting fs with errors, running e2fsck is recommended
[   98.061947] EXT4-fs (dm-3): recovery complete
[   98.061957] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none.
[  104.026099] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:390: comm ext4lazyinit: bg 3999: bad block bitmap checksum
[  104.026106] Aborting journal on device dm-3-8.
[  104.065619] EXT4-fs (dm-3): Remounting filesystem read-only
[  398.089528] EXT4-fs (dm-3): error count since last fsck: 1804
[  398.089540] EXT4-fs (dm-3): initial error at time 1671056071: ext4_lookup:1836: inode 32640029
[  398.089552] EXT4-fs (dm-3): last error at time 1673554480: ext4_validate_block_bitmap:390
[  552.946132] EXT4-fs (dm-3): unmounting filesystem.
[  781.480164] EXT4-fs warning (device dm-3): ext4_clear_journal_err:6017: Filesystem error recorded from previous mount: IO failure
[  781.480171] EXT4-fs warning (device dm-3): ext4_clear_journal_err:6019: Marking fs in need of filesystem check.
[  781.521341] EXT4-fs (dm-3): warning: mounting fs with errors, running e2fsck is recommended
[  781.547854] EXT4-fs (dm-3): recovery complete
[  781.568344] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none.
[  787.456453] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:390: comm ext4lazyinit: bg 3999: bad block bitmap checksum
[  787.456460] Aborting journal on device dm-3-8.
[  787.488395] EXT4-fs (dm-3): Remounting filesystem read-only
0

1 Answer 1

2

The system log extract reveals that this is not a problem with LUKS encryption, but with the "usage" of the unlocked EXT4 file system on the encrypted partition: at some point in the past, a filesystem inconsistency occurred, e.g. due to it being removed without properly unmounting, power outage, or any other reasons. The error was noted when the filesystem driver tried to start the journal of the file system

Quote:

ext4_clear_journal_err:6017: Filesystem error recorded from previous mount: IO failure

This means that the filesystem is in a "bad" state, and is in need of repair.

Quote:

warning: mounting fs with errors, running e2fsck is recommended

For the moment, the file system is mounted, but with the advice to perform a filesystem check. It is not recommended to use any write operations on filesystems in that state.

Ultimately, the kernel notices further inconsistencies in the filesystem structure

EXT4-fs error (device dm-3): ext4_validate_block_bitmap:390: comm ext4lazyinit: bg 3999: bad block bitmap checksum

For that reason, the kernel has decided to mount it read-only so that you can access files, but not perform any further modifications that may aggravate the internal inconsistency (to the point where it may actually be corrupted). You can see from the timestamps that it takes a moment for that to happen, so there may be a short time window when you actually can (but still shouldn't) write to the partition.

To solve this problem, you should do as the filesystem driver recommends:

  1. Perform a backup of all data on the encrypted partition - it is still readable, after all.

  2. Identify the raw device exposed by LUKS. You can do so by invoking lsblk; the unlocked LUKS partition will be shown as device of type crypt:

    ~$ sudo lsblk
    NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
    ...
    sdb               ..:..  ... ...  .. disk
    +- sdb1           ..:..  ... ...  .. part
       +- some_name   ..:..  ... ...  .. crypt /path/to/mountpoint
    

    Here, all ... are placeholders for actual but varying values. The relevant point is that in the example, the unlocked mapping to the encrypted raw device is /dev/mapper/some_nome, and it is mounted on /path/to/mountpoint.

  3. Unmount the filesystem, but without re-locking the LUKS partition. This needs to be done "manually" because using the "eject" function provided by file managers usually re-locks the partitions in the same process. Make sure no process accesses files or directories on the encrypted partition, then execute

    ~$ sudo umount /path/to/mountpoint
    
  4. Perform a file system check on the file system on the unlocked encrypted partition

    ~$ sudo e2fsck -v /dev/mapper/some_name
    

    You will likely get tons of error messages, and be asked if you want to perform a number of proposed repairs. The exact question depends on the nature of the inconsistency; you will need to consult your favorite search engine on the meaning and to determine if that is a good idea or not.

  5. Once the operation is finished, you can mount the partition again:

    ~$ sudo mount /dev/mapper/some_name /path/to/mountpoint
    

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .