How to check encrypted home directory by fsck

Hello,

I have some files in Trash folder which can’t be deleted (neither like root). I would like to check the home directory by fsck to deal with the files. It is the standard home directory encryption set by the installation process (I suppose an encrypted LUKS container).

How to run the fsck inside the home directory?

You should be able to use:


# cryptsetup luksOpen "/path/to/container" "symbolic_name"

Replace quoted parts by real value. You can make up a symbolic name, such as “my_home”.

Do that at a command line root login, before you login as yourself.

Then (with the symbolic name I suggested) you could check with


# fsck /dev/mapper/my_home

When done, unopen


# cryptsetup luksClose "symbolic_name".

Then resume using it in the normal way.

Thank you for the advise, but I cant open the Luks image:

cryptsetup luksOpen /home/image.img my_home

and it doesn’t accept my password:

No key available with this passphrase.

I’ve tried:

cryptsetup luksOpen --key-file /home/image.key /home/image.img my_home 

and the response was

No key available with this passphrase.

I can log into account normally, the problem appears when I try to access it manually.

Interesting.

I’ll experiment with that, but it will be a few days before I can start experimenting. I mostly use an encrypted partition, rather than an encrypted home directory. I briefly experimented with encrypted home directory a while back, but I did not check that particular detail.

My current view is that “ecryptfs” provides a better way of setting up an encrypted home directory. This is the ubuntu way of doing it, but not fully supported with opensuse. Instead, you would have to install and setup a user first, then later switch that user to an ecryptfs home directory.

The file with the key is also encrypted by the login password, so you have to encrypted first:

  openssl aes-256-cbc -d -in /home/image.key | cryptsetup luksOpen /home/image.img my_home  

The image was heavily corrupted, but luckily the fsck fix it. Is it save to run the fsck on home partition (where the image file is)? I’m bit afraid, that it could corrupt the consistency of the image.

Okay. I wondered about that possibility (that the LUKS key was encrypted in another file). I’m glad you were able to track that down.

The image was heavily corrupted, but luckily the fsck fix it. Is it save to run the fsck on home partition (where the image file is)? I’m bit afraid, that it could corrupt the consistency of the image.

It should be safe, as “fsck” on a file system mainly deals with metadata, rather than file content. But I guess there’s still a slight risk.

If you want to play it extra safe, then boot with live media. Then mount your home partition read-only (to not further corrupt it). Then copy the container file to elsewhere (say an external drive).

Then umount the partition, and run fsck. If all goes well, you can delete the backup of the container file. If there’s a problem, you can copy it back from your backup.