Are inode unique and persistent in reverse mode ?

[hpn789]

Hi, I would like to use gocryptfs in reverse mode for cloud backup and I would like to know if the inodes number are unique and persistent in the encrypted view? I would like to use "Smart rsync backup" (https://github.com/wapsi/smart-rsync-backup) which list files moved and renamed since the last time and this tools only works if inodes are unique and persistent. I searched in the documentation but did find the answer. Thank you for your help :)

[rfjakob]

Hi! The inode numbers are always unique for one reverse mount.

Under the following condition they are also persistent:

• No mountpoints below the plaintext directory

If there are mountpoints, the inode numbers depend on the order of file accesses.

EDIT: see https://github.com/rfjakob/gocryptfs/issues/606#issuecomment-925207979

[hpn789]

Thank you for the answer, unfortunatly I have found that inode change when I mount, unmount and remount depending of what file I read first, is this normal ? (I'm on version 2.1 on debian 9 (omv))

[rfjakob]

No mountpoints inside?

[hpn789]

No, I made i simple test : I have a folder "plain" with files tree

• plain/ -----Test/ ----------test.txt

Init with : "gocryptfs -reverse -init plain" Make directory cipher and mounted with "gocryptfs -reverse plain cipher" with resulting files tree:

• cipher/ -----gocryptfs.conf -----gocryptfs.diriv -----5mTRSUgmQqJTSV4ZxFV3Cw/ ----------gocryptfs.diriv ----------pCRgkYSjYgyFYLC2o64snQ

a) If I make :

• ls cipher
• ls -il 5mTRSUgmQqJTSV4ZxFV3Cw The result give me an inode for the file "pCRgkYSjYgyFYLC2o64snQ", for exemple "9223372036854775812"

b) If then I make :

• fusermount -u cipher
• gocryptfs -reverse plain cipher
• then directly "ls -il 5mTRSUgmQqJTSV4ZxFV3Cw" The inode of "pCRgkYSjYgyFYLC2o64snQ" is not the same : "9223372036854775809" :(

The really close number shows it depends of the order of access. If I repeat a) or b) mutiple times it always gives me the same inode.

[rfjakob]

Version v2.1 right? ( https://github.com/rfjakob/gocryptfs/releases/tag/v2.1 )

[rfjakob]

Hmm, looks good here:

$ ./gocryptfs -version
gocryptfs v2.1 without_openssl; go-fuse v2.1.1-0.20210802120645-15a8bb029a4e; 2021-08-18 go1.17 linux/amd64

$ tree --inodes plain
plain
└── [143969475]  Test
    └── [143969476]  test.txt

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher
cipher
├── [143969475]  8Zscd3_NV5YtsYE8Foe-ww
│   ├── [281475120680131]  gocryptfs.diriv
│   └── [143969476]  Xc1BUkX5f65xYtftpodE6w
├── [143969477]  gocryptfs.conf
└── [281475120680130]  gocryptfs.diriv

$ fusermount -u cipher

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher
cipher
├── [143969475]  8Zscd3_NV5YtsYE8Foe-ww
│   ├── [281475120680131]  gocryptfs.diriv
│   └── [143969476]  Xc1BUkX5f65xYtftpodE6w
├── [143969477]  gocryptfs.conf
└── [281475120680130]  gocryptfs.diriv

[hpn789]

gocryptfs -version : gocryptfs v2.1.HEAD; go-fuse v2.1.1-0.20210802120645-15a8bb029a4e; 2021-09-21 go1.17.1 linux/amd64

[rfjakob]

Can you run

tree --inodes plain

please?

[hpn789]

I have not compile the without_openssl but I think it's the same. For your test the 2nd time do : "tree --inodes cipher/8Zscd3_NV5YtsYE8Foe-ww" not "tree --inodes cipher" because it access all file in the same order the 2 times in your exemple.

[rfjakob]

Good point, but no:

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher/8Zscd3_NV5YtsYE8Foe-ww
cipher/8Zscd3_NV5YtsYE8Foe-ww
├── [281475120680131]  gocryptfs.diriv
└── [143969476]  Xc1BUkX5f65xYtftpodE6w

[hpn789]

Can you run

tree --inodes plain

please?

It gives me

tree --inodes plain
plain
└── [-2518476705809431667]  Test
    └── [-1819540082368938331]  Change.jpg

1 directory, 1 file

(sorry the file name is not Test.txt but Change.jpg)

[rfjakob]

Wow, negative inode numbers! That's something new!

What kind of filesystem is this?

[hpn789]

Effectivly I'm on unionfs in this volume, I gonna try on an ext4 volume to see if it comes for this.

[hpn789]

I think it come from unionfs because I rerun my test in a folder in ext4 volume and I have not the issue, so weird.

# gocryptfs -reverse plain cipher
Password:
Decrypting master key
Filesystem mounted and ready.
# ls cipher/
gocryptfs.conf  gocryptfs.diriv  Jx0rm8L_M1_Q48OypQOeEg
# ls -il cipher/Jx0rm8L_M1_Q48OypQOeEg
total 8
       24119222 -rw-r--r-- 1 root users 55 sept. 22 20:40 4svlZfEWcwn-_KJn7KD8NQ
281475000829881 -r--r--r-- 1 root users 16 sept. 22 20:42 gocryptfs.diriv
# fusermount -u cipher
# gocryptfs -reverse plain cipher
Password:
Decrypting master key
Filesystem mounted and ready.
# ls -il cipher/Jx0rm8L_M1_Q48OypQOeEg
total 8
       24119222 -rw-r--r-- 1 root users 55 sept. 22 20:40 4svlZfEWcwn-_KJn7KD8NQ
281475000829881 -r--r--r-- 1 root users 16 sept. 22 20:42 gocryptfs.diriv

[rfjakob]

Oh I see. I forgot the 2nd condition for persistent inode numbers. So https://github.com/rfjakob/gocryptfs/issues/606#issuecomment-925001282 should have read:

---

The inode numbers are always unique for one reverse mount.

Under the following condition they are also persistent:

• No mountpoints below the plaintext directory
• Inode numbers in the plaintext directory are below 281474976710655

If there are mountpoints, the inode numbers depend on the order of file accesses.

[hpn789]

Ok thank you, I gonna try to figure out a solution on my side, any idea why this limitation of "281474976710655" ?

[hpn789]

For those who would have the same issue of non persistent inodes in encrypted folder when combining unionfs/mergerfs with gocryptfs in reverse mode I have found a solution.

If your have no mount point under the plain text directory the issues occurs when inodes are greater than "281474976710655" which is the max value on 48bits. The default conf of mergerfs calculate inodes on 64bits but you can add the parameters :

• "inodecalc=hybrid-hash32"

to mergerfs to always have 32bits inodes and be compatible with gocryptfs.

In the future, as more and more system use 64bits inodes I think gocryptfs should be compatible with them.

[rfjakob]

Yes, 281474976710655 is the max having 48 bits. Values above this are reserved for other things:

• gocryptfs.diriv files
• gocryptfs.longname files
• files on other mountpoints

I read about how mergerfs generates inode numbers at https://github.com/trapexit/mergerfs#inodecalc . You should be aware that mergerfs does not guarantee unique inode numbers!

gocryptfs does guarantee unique inode numbers, but as a downside, it needs the reserved number range.

[hpn789]

Yes, I'm aware that mergerfs does not guarantee unique inode numbers, until here I had no tools which making use of inodes or reporting issue. One more question, does gocryptfs guarantee uniques inodes number in the cipher view (reverse mode) even if the data in the plain folder are on mergerfs and so doesn't guarantee unique inodes?

[rfjakob]

does gocryptfs guarantee uniques inodes number in the cipher view (reverse mode) even if the data in the plain folder are on mergerfs and so doesn't guarantee unique inodes?

No!