Unlocking of encrypted directory inside of disk partition image does not work while fscrypt confirms "ready for use"

[cs224]

On machine A I have created a partition image with the "dd" tool. On machine B I then mount this partition image via a loopback device and want to fscrypt unlock a given directory with a custom protector. On both machines I use ubuntu 22.04 LTS with fscrypt version v0.3.3.

On machine B I mount the image and then unlock the directory and I get a "ready for use" confirmation. This is a policy_version:1 directory:

root@m:/media/cs/elements# mount -o loop ./2023-11-08-nvme1n1-linuxp2 /mnt
root@m:/media/cs/elements# fscrypt unlock /mnt/home/cs --user=root
The available protectors are: 
0 - login protector for [uid 1001: unknown user]
1 - custom protector "passphrase_cs"
Enter the number of protector to use: 1
Enter custom passphrase for protector "passphrase_cs": 
"/mnt/home/cs" is now unlocked and ready for use.
root@m:/media/cs/elements# ll /mnt/home/cs

When I then look into the directory /mnt/home/cs I still see the scrambled files.

Here is the output of fscrypt status and the /mnt/.fscrypt/ directory:

root@m:/# fscrypt status /mnt/home/cs
"/mnt/home/cs" is encrypted with fscrypt.

Policy:   37bb07078f2ec061
Options:  padding:32 contents:AES_256_XTS filenames:AES_256_CTS policy_version:1 
Unlocked: Yes

Protected with 2 protectors:
PROTECTOR         LINKED  DESCRIPTION
b0bdca05526ef26d  No      login protector for [uid 1001: unknown user]
5357a2a6f244a39c  No      custom protector "passphrase_cs"

root@m:/# ll /mnt/.fscrypt/
total 16
drwxr-xr-x  4 root root 4096 Nov 30  2018 ./
drwxr-xr-x 27 root root 4096 Mai 26  2022 ../
drwxrwxrwt  2 root root 4096 Okt 26  2021 policies/
drwxrwxrwt  2 root root 4096 Nov  7  2021 protectors/

Any suggestions what I can do to make this work?

Thanks!

[Joe Richey]

Confusing or contradictory views of encrypted files are one of the main downsides of V1 policies. Could you try the same setup but with V2 policies?

The documentation should have an explanation of how to setup such policies (you may need to update /etc/fscrypt.conf). Let me know if you have any questions.

[Eric Biggers]

Yes, this issue is probably caused by using an older version of fscrypt that uses v1 encryption policies. This issue has already been fixed. See https://github.com/google/fscrypt#some-processes-cant-access-unlocked-encrypted-files for what to do about it.

[cs224]

Thank you very much for your hints. I'll try your suggestions in the next couple of days.

[Eric Biggers]

I don't think there's anything else we can do here, so I'm closing this issue.