Encrypted overlay filesystem written in Go

Go support Mac OS X, as does the FUSE library we use, go-fuse.

gocrypts may actually work out of the box on OSX, but there probably are small issues that have to be sorted out.

At the very least, gocryptfs has to be tested on OSX. As I do not have a Mac to test on, this would be an opportunity for somebody from the Mac community to step up. Please comment here if you are interested.

Hi @rfjakob,

Thank you for this great application! The reverse mode is what really sets it apart from other options.

I checked the issues, and it doesn't seem to be discussed yet, but what do you think about adding support for a different collection of encryption primitives that are better suited for more low-end devices?

I'm running gocryptfs on a few ARMv6/7 based NAS machines, they are nice: low energy, and quite fast. But they lack native AES instructions, my fastest ARM device (Odroid XU4) maxes out at 40MB/s, while for example the raspberry-pi's and friends are quite a bit slower (rpi1 is at 15MB/s).

Maybe Google Adiantum (also added to linux kernel 5.0 for cryptfs) is a nice fit, Adiantum is based on XChaCha12 and Poly1305 and is roughly 5 quicker than AES-XTS for devices without AES instructions.

For the reverse mode maybe something based on ChaCha20Poly1305?

Just for comparison, on my Odroid XU4, ChaCha20Poly1305 runs at 320MB/s, on my RPi1 it gets close to 40MB/s.

So I'm just wondering what your view is on this topic.

Cheers, Davy

Needs further analysis:

_porter 28 not complete
cp: cannot create regular file '/var/tmp/check-gocryptfs/scratchdir/sub_28/origin/file_548': No such file or directory

https://github.com/rfjakob/gocryptfs/blob/master/Documentation/XFSTESTS.md#generic273

Hey there,

I am getting this (title) message very often while copying data. In the System Console I see:

19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:51,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:52,000 kernel[0]: osxfuse: vnode changed generation
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)
19/02/18 21:25:53,000 kernel[0]: osxfuse: fuse_vnop_readdir failed (err=22)

Although this seems to occur sometimes without the error in Finder. When I copy via cpthen some files do not get copied and cp prints Stale NFS file handle

The debug output of gocrypt itself does not show any errors. I am using version gocryptfs v1.4.3; go-fuse [vendored]; 2018-02-02 go1.9.3 (Homebrew) and OSX Fuse version 3.7.1.

Thanks a lot, Magnus

I started using gocryptfs (latest version) on macOS High Sierra and noticed that each time I eject my encrypted volume and remount it, that the creation and modification dates are reset to 1970-01-01. Is this expected behaviour?

I mount my dirs using

gocryptfs -ko local /path/to/encDir /Volumes/encDir

Also mounting them without the -ko local option has the same result.

Add an option similar to the --reverse option for encfs:

Normally EncFS provides a plaintext view of data on demand. Normally it stores enciphered data and displays plaintext data. With --reverse it takes as source plaintext data and produces enciphered data on-demand. This can be useful for creating remote encrypted backups, where you do not wish to keep the local files unencrypted.

For example, the following would create an encrypted view in /tmp/crypt-view.

encfs --reverse /home/me /tmp/crypt-view You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted data. You must also keep a copy of the file /home/me/.encfs5 which contains the filesystem information. Together, the two can be used to reproduce the unencrypted data: ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view Now /tmp/plain-view contains the same data as /home/me Note that --reverse mode only works with limited configuration options, so many settings may be disabled when used.

(Quote from encfs man page)

Use case

• /tmp/encrypted is an Amazon Cloud Drive folder, mounted read-only using rclone
• /tmp/clear is the gocryptfs deciphered version of the above.

Copying a 300MB file (ciphered) from /tmp/encrypted, I get around 5-6MBps, which is OK, considering my bandwidth is 10MBps. Copying the same file from /tmp/clear yields extremely poor speeds (from 100KBps to 1MBps). Speed is not limited by the CPU. Tracing read requests in rclone shows read sizes from 4KB to 128KB occuring at low frequency (thus low througput)

Any advice would be greatly appreciated.

Environment

• Debian Stretch, x86_64
• gocryptfs 1.2.1
• Ciphered volume has the following features:
  • version: 2
  • flags: GCMIV128, DirIV, EMENames, LongNames, AESSIV
• rclone 1.35, mount max-read-ahead set to 16MB

Because it's Go, could it be made to run on Windows as well? (Cross-platform support is an attractive feature.)

The problem with windows is that it does not have FUSE support. Linux has it built-in and Mac has the OSXFuse project. On windows, the only thing i am aware of is http://encfsmp.sourceforge.net/ . They SOMEHOW managed to get encfs (which also uses FUSE) running on windows, using a closed-source windows kernel driver and lots of black magic.

See discussion here https://github.com/rfjakob/gocryptfs/issues/2#issuecomment-152955769 and here https://github.com/rfjakob/gocryptfs/issues/2#issuecomment-152962990

While rather unlikely in practice, a file descriptor of 0 is completely valid and should not be treated as an error [1]. Both open and Dup typically return the smallest available file descriptor and only negative values are errors. If the user starts gocryptfs with stdin (fd == 0) closed and triggers the dircache code fast enough (not sure if that is actually possible), this could lead to a panic / unexpected behavior (e.g., in the fd validation in Store).

[1] https://unix.stackexchange.com/questions/100611/aix-open-file-descriptor-is-zero

I'm trying to set up gocryptfs on Ubuntu 14.04.1 LTS. I downloaded the binary release 1.2.1 from here (Debian version) and tried initilaizing a folder. But I get the mentioned error:

$ cd ~ $ mkdir plain cipher $ ./gocryptfs -init cipher Choose a password for protecting your files. Password: Repeat: WriteDirIV: open /home/<username>/cipher/gocryptfs.diriv: permission denied open /home/<username>/cipher/gocryptfs.diriv: permission denied

In case this matters: my home folder is an NFS4 mount.

default compilation results in the output below, with reported error 'FIDO_ERR_UNSUPPORTED_OPTION'

$ gocryptfs -init -d -fido2="IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" foo.gocryptfs OpenSSL disabled, using Go GCM FIDO2 Register: interact with your device ... callFidoCommand: executing "/usr/local/bin/fido2-cred" with args [fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice] fido2-cred: fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_OPTION fido2-cred failed with exit status 1

calling the reported command line shows that the space in the device string is the troublemaker [Edit : wrong assumption. -v was the root cause] $ fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice fido2-cred: unknown type OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice

I added the patch below to the brew formula in order to have the space escaped :

inreplace "./internal/fido2/fido2.go",
          " device)",
          ' fmt.Sprintf("%s",strings.ReplaceAll(device," ","\\\\\\\\ ")))'

results after the patch : the space is now escaped, and the reported error changed to 'FIDO_ERR_INTERNAL'

$ gocryptfs -init -d -fido2="IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" foo.gocryptfs OpenSSL disabled, using Go GCM FIDO2 Register: interact with your device ... callFidoCommand: executing "/usr/local/bin/fido2-cred" with args [fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey\ OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice] fido2-cred: fido_dev_open IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey\ OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice: FIDO_ERR_INTERNAL fido2-cred failed with exit status 1

invoking fido2-creds with the latest reported command line does not report any error. I'm still investigating to find what goes wrong.

Team, I hit an issue when using the following version of gocryptfs: gocryptfs v2.3 without_openssl; go-fuse v2.1.1-0.20211219085202-934a183ed914; 2022-08-28 go1.19 linux/amd6

Here are my computer details:

• uname -a returned Linux xubuntu 5.15.0-25-generic #25-Ubuntu SMP Wed Mar 30 15:54:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
• cat /etc/*release* showed:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04 LTS"
PRETTY_NAME="Ubuntu 22.04 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

• lsmem showed:

RANGE                                 SIZE  STATE REMOVABLE  BLOCK
0x0000000000000000-0x000000007fffffff   2G online       yes   0-15
0x0000000100000000-0x000000047fffffff  14G online       yes 32-143

Memory block size:       128M
Total online memory:      16G
Total offline memory:      0B

• lscpu showed:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) m7-6Y75 CPU @ 1.20GHz
    CPU family:          6
    Model:               78
    Thread(s) per core:  2
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            3
    CPU max MHz:         3100.0000
    CPU min MHz:         400.0000
    BogoMIPS:            2400.00
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
                         a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss 
                         ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art
                          arch_perfmon pebs bts rep_good nopl xtopology nonstop_
                         tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cp
                         l vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid ss
                         e4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes 
                         xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_f
                         ault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow
                          vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust 
                         sgx bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx sma
                         p clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dt
                         herm ida arat pln pts hwp hwp_notify hwp_act_window hwp
                         _epp md_clear flush_l1d
Virtualization features: 
  Virtualization:        VT-x
Caches (sum of all):     
  L1d:                   64 KiB (2 instances)
  L1i:                   64 KiB (2 instances)
  L2:                    512 KiB (2 instances)
  L3:                    4 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-3
Vulnerabilities:         
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Mitigation; PTE Inversion; VMX conditional cache flushe
                         s, SMT vulnerable
  Mds:                   Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown:              Mitigation; PTI
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
                          and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer
                          sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIB
                         P conditional, RSB filling
  Srbds:                 Mitigation; Microcode
  Tsx async abort:       Mitigation; TSX disabled

When I used the -init with -scryptn 23_, I didn't observe any error (files is the name of the directory and master keys have been removed from the output):

gocryptfs -init -raw64 -xchacha -noexec -fg -nosyslog -scryptn 23 files
Choose a password for protecting your files.
Password: 
Repeat: 

Your master key is:

    xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-
    xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs files MOUNTPOINT

When I use 24 (and above as well - for eg 26 and 28) as the value of the -scryptn option, I see:

gocryptfs -init -raw64 -xchacha -noexec -fg -nosyslog -scryptn 24 files
Choose a password for protecting your files.
Password: 
Repeat: 

Your master key is:

    xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-
    xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
fatal error: runtime: out of memory

runtime stack:
runtime.throw({0x64e8b2?, 0x2030?})
	runtime/panic.go:1047 +0x5d fp=0x7ffc64780170 sp=0x7ffc64780140 pc=0x43667d
runtime.sysMapOS(0xc000400000, 0x400000000?)
	runtime/mem_linux.go:187 +0x11b fp=0x7ffc647801b8 sp=0x7ffc64780170 pc=0x41829b
runtime.sysMap(0x7f67a0?, 0x7f8da3c85000?, 0x42b7a0?)
	runtime/mem.go:142 +0x35 fp=0x7ffc647801e8 sp=0x7ffc647801b8 pc=0x417c75
runtime.(*mheap).grow(0x7f67a0, 0x200000?)
	runtime/mheap.go:1459 +0x23d fp=0x7ffc64780258 sp=0x7ffc647801e8 pc=0x42879d
runtime.(*mheap).allocSpan(0x7f67a0, 0x200000, 0x0, 0x1)
	runtime/mheap.go:1191 +0x1be fp=0x7ffc647802f0 sp=0x7ffc64780258 pc=0x427efe
runtime.(*mheap).alloc.func1()
	runtime/mheap.go:910 +0x65 fp=0x7ffc64780338 sp=0x7ffc647802f0 pc=0x427985
runtime.systemstack()
	runtime/asm_amd64.s:492 +0x49 fp=0x7ffc64780340 sp=0x7ffc64780338 pc=0x467829

goroutine 1 [running]:
runtime.systemstack_switch()
	runtime/asm_amd64.s:459 fp=0xc00008d3e8 sp=0xc00008d3e0 pc=0x4677c0
runtime.(*mheap).alloc(0x40ca3e?, 0x7f8d7c675218?, 0xe0?)
	runtime/mheap.go:904 +0x65 fp=0xc00008d430 sp=0xc00008d3e8 pc=0x4278c5
runtime.(*mcache).allocLarge(0x7f8da3ca5a68?, 0x400000000, 0x1)
	runtime/mcache.go:233 +0x85 fp=0xc00008d480 sp=0xc00008d430 pc=0x416c05
runtime.mallocgc(0x400000000, 0x602e60, 0x1)
	runtime/malloc.go:1029 +0x57e fp=0xc00008d4f8 sp=0xc00008d480 pc=0x40d13e
runtime.makeslice(0x0?, 0x7deca0?, 0xc00008d570?)
	runtime/slice.go:103 +0x52 fp=0xc00008d520 sp=0xc00008d4f8 pc=0x44e0d2
golang.org/x/crypto/scrypt.Key({0xc000124980?, 0x4, 0x8}, {0xc0001300e0, 0x20, 0x20}, 0x1000000, 0xc0001300e0?, 0x1, 0x20)
	golang.org/x/[email protected]/scrypt/scrypt.go:204 +0x18a fp=0xc00008d5d8 sp=0xc00008d520 pc=0x570daa
github.com/rfjakob/gocryptfs/v2/internal/configfile.(*ScryptKDF).DeriveKey(0xc00016cfc8, {0xc000124980, 0x4, 0x8})
	github.com/rfjakob/gocryptfs/v2/internal/configfile/scrypt.go:70 +0xd3 fp=0xc00008d660 sp=0xc00008d5d8 pc=0x573693
github.com/rfjakob/gocryptfs/v2/internal/configfile.(*ConfFile).EncryptKey(0xc00016cfa0, {0xc000130080, 0x20, 0x20}, {0xc000124980, 0x4, 0x8}, 0x30?)
	github.com/rfjakob/gocryptfs/v2/internal/configfile/config_file.go:246 +0x12d fp=0xc00008d738 sp=0xc00008d660 pc=0x572d0d
github.com/rfjakob/gocryptfs/v2/internal/configfile.Create(0xc00008da88)
	github.com/rfjakob/gocryptfs/v2/internal/configfile/config_file.go:135 +0x885 fp=0xc00008d990 sp=0xc00008d738 pc=0x571905
main.initDir(0xc00008dda0)
	github.com/rfjakob/gocryptfs/v2/init_dir.go:99 +0x507 fp=0xc00008db20 sp=0xc00008d990 pc=0x5e3967
main.main()
	github.com/rfjakob/gocryptfs/v2/main.go:325 +0xc94 fp=0xc00008df80 sp=0xc00008db20 pc=0x5e5734
runtime.main()
	runtime/proc.go:250 +0x212 fp=0xc00008dfe0 sp=0xc00008df80 pc=0x438ed2
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc00008dfe8 sp=0xc00008dfe0 pc=0x4698a1

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	runtime/proc.go:363 +0xd6 fp=0xc00003afb0 sp=0xc00003af90 pc=0x439296
runtime.goparkunlock(...)
	runtime/proc.go:369
runtime.forcegchelper()
	runtime/proc.go:302 +0xad fp=0xc00003afe0 sp=0xc00003afb0 pc=0x43912d
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc00003afe8 sp=0xc00003afe0 pc=0x4698a1
created by runtime.init.6
	runtime/proc.go:290 +0x25

goroutine 17 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
	runtime/proc.go:363 +0xd6 fp=0xc000036790 sp=0xc000036770 pc=0x439296
runtime.goparkunlock(...)
	runtime/proc.go:369
runtime.bgsweep(0x0?)
	runtime/mgcsweep.go:278 +0x8e fp=0xc0000367c8 sp=0xc000036790 pc=0x42496e
runtime.gcenable.func1()
	runtime/mgc.go:178 +0x26 fp=0xc0000367e0 sp=0xc0000367c8 pc=0x419626
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc0000367e8 sp=0xc0000367e0 pc=0x4698a1
created by runtime.gcenable
	runtime/mgc.go:178 +0x6b

goroutine 18 [GC scavenge wait]:
runtime.gopark(0xc000094000?, 0x697f48?, 0x1?, 0x0?, 0x0?)
	runtime/proc.go:363 +0xd6 fp=0xc000036f70 sp=0xc000036f50 pc=0x439296
runtime.goparkunlock(...)
	runtime/proc.go:369
runtime.(*scavengerState).park(0x7de4e0)
	runtime/mgcscavenge.go:389 +0x53 fp=0xc000036fa0 sp=0xc000036f70 pc=0x422a13
runtime.bgscavenge(0x0?)
	runtime/mgcscavenge.go:617 +0x45 fp=0xc000036fc8 sp=0xc000036fa0 pc=0x422fe5
runtime.gcenable.func2()
	runtime/mgc.go:179 +0x26 fp=0xc000036fe0 sp=0xc000036fc8 pc=0x4195c6
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc000036fe8 sp=0xc000036fe0 pc=0x4698a1
created by runtime.gcenable
	runtime/mgc.go:179 +0xaa

goroutine 33 [finalizer wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0xc00003a770?)
	runtime/proc.go:363 +0xd6 fp=0xc00003a628 sp=0xc00003a608 pc=0x439296
runtime.goparkunlock(...)
	runtime/proc.go:369
runtime.runfinq()
	runtime/mfinal.go:180 +0x10f fp=0xc00003a7e0 sp=0xc00003a628 pc=0x41872f
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc00003a7e8 sp=0xc00003a7e0 pc=0x4698a1
created by runtime.createfing
	runtime/mfinal.go:157 +0x45

goroutine 34 [chan send]:
runtime.gopark(0x0?, 0xc00003e400?, 0x28?, 0x67?, 0x56979e?)
	runtime/proc.go:363 +0xd6 fp=0xc0001566d8 sp=0xc0001566b8 pc=0x439296
runtime.chansend(0xc0001000c0, 0xc0001567a0, 0x1, 0x0?)
	runtime/chan.go:259 +0x42c fp=0xc000156760 sp=0xc0001566d8 pc=0x405acc
runtime.chansend1(0x0?, 0x0?)
	runtime/chan.go:145 +0x1d fp=0xc000156790 sp=0xc000156760 pc=0x40567d
github.com/rfjakob/gocryptfs/v2/internal/cryptocore.(*randPrefetcherT).refillWorker(0x7de2c0)
	github.com/rfjakob/gocryptfs/v2/internal/cryptocore/randprefetch.go:51 +0x47 fp=0xc0001567c8 sp=0xc000156790 pc=0x56c2c7
github.com/rfjakob/gocryptfs/v2/internal/cryptocore.init.0.func1()
	github.com/rfjakob/gocryptfs/v2/internal/cryptocore/randprefetch.go:16 +0x26 fp=0xc0001567e0 sp=0xc0001567c8 pc=0x56bd66
runtime.goexit()
	runtime/asm_amd64.s:1594 +0x1 fp=0xc0001567e8 sp=0xc0001567e0 pc=0x4698a1
created by github.com/rfjakob/gocryptfs/v2/internal/cryptocore.init.0
	github.com/rfjakob/gocryptfs/v2/internal/cryptocore/randprefetch.go:16 +0x6b

This is my first time using gocryptfs and it is possible I might have used it incorrectly (I did go through the manpage though). I searched through all the github issues but I couldn't find one that matched what I observed. Hence, I created a new one (pardon me in case I didn't search thoroughly and the issue was already reported).

If there is any additional information needed (for eg. trying out debug builds), please let me know.

during mount, before asking for a FIDO device (used during init) try to find a device. if there is only one device use this device if there are no devices or more than one, report the issue and ask for a device (same as now)

in https://github.com/rfjakob/gocryptfs/issues/571 user verification was removed. as a result currently only user presence is configured. I did not find an option to enable client pin.

I'd like to suggest to add options similar to systemd-cryptenroll

• fido2-device
• fido2-with-client-pin=BOOL, defaul=yes
• fido2-with-user-presence=BOOL, default=yes
• fido2-with-user-verification=BOOL, default=no

the selected options should be added to gocryptfs.conf

Possible solution depending on the selected option, add -t [up|uv|pin]to line https://github.com/rfjakob/gocryptfs/blob/69d88505fd7f4cb0d9e4f1918de296342fe05858/internal/fido2/fido2.go#L44

Regardless of root or non-root, gocryptfs works out of the box, as long I operate on natiave volumes (ext4)

But when I try to use an encrypted folder, located on a rclone mounted volume, it does not work. The target folder would be outside of the volume, of course.

I always get an Operation not permitted, when I try to create files. Creating folders works. Of course, I also tried every possible combination of ownership, permissions, and even the allow_all/force_owner.

Site note: encfs works without any errors.

OS: Debian 11 rclone: 1.60.1 gocryptfs: 1.8 and 2.3

Recent linux kernels (I think after 4.18?) allow mounts within unprivileged namespaces without using a suid like fusermount. This is especially advantageous within unprivileged sandboxes that have nonewprivs set (for example, flatpaks and other things using bwrap), hence cannot use suids like fusermount even if any are installed. Is it possible for gocryptfs to attempt to use mount before falling back on fusermount in such cases?