Issue with idle-unmount and files being used

[petrarca-arezzo]

I'm seeing a strage (I think) behaviour with the idle-unmount option - if I mount a cipherdir with the idle option on and have a file opened in an editior gocryptfs does unmount the directory. My expectation would be that it would be left mounted as long as files are in use/opened and only unmounts it once all files are closed. Manually unmounting gives an error as expected though.

A sample debug output looks like this:

Checking for idle (isIdle = false, open = 0): 2020-12-14 10:13:23.774914275 +0100 CET m=+81.285029634
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:14:38.775224258 +0100 CET m=+156.285339542
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:15:53.775592901 +0100 CET m=+231.285708140
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:17:08.776033063 +0100 CET m=+306.286148317
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:18:23.7764397 +0100 CET m=+381.286554924
Filesystem idle; unmounting: /home/user/secret
unmount: srv.Unmount returned /bin/fusermount: failed to unmount /home/user/secret: Device or resource busy
 (code exit status 1)
Trying lazy unmount
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:19:39.091255942 +0100 CET m=+456.601371260
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:20:54.091621515 +0100 CET m=+531.601736754
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:22:09.091971152 +0100 CET m=+606.602086390
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:23:24.092327712 +0100 CET m=+681.602442945
Filesystem idle; unmounting: /home/user/secret
unmount: srv.Unmount returned /bin/fusermount: entry for /home/user/secret not found in /etc/mtab
 (code exit status 1)
Trying lazy unmount
fusermount: entry for /home/user/secret not found in /etc/mtab
Checking for idle (isIdle = true, open = 0): 2020-12-14 10:24:39.40682465 +0100 CET m=+756.916939948

This is happening with
gocryptfs 1.7.1; go-fuse 0.0~git20190214.58dcd77; 2019-12-26 go1.13.5 linux/amd64

[rfjakob]

I think the problem is that the editor copies the file into memory, but does not keep it actually open. At least that's what nano seems to do:

Open file

$ nano /tmp/foo.txt

In second terminal check what files nano has open (note: foo.txt is not here)

$ lsof -p $(pgrep nano)
COMMAND   PID  USER   FD   TYPE DEVICE  SIZE/OFF    NODE NAME
nano    14682 jakob  cwd    DIR  253,0      4096       2 /
nano    14682 jakob  rtd    DIR  253,0      4096       2 /
nano    14682 jakob  txt    REG  253,0    347200 6355383 /usr/bin/nano
nano    14682 jakob  mem    REG  253,0 223542144 6292603 /usr/lib/locale/locale-archive
nano    14682 jakob  mem    REG  253,0     37384 6298839 /usr/lib64/libdl-2.32.so
nano    14682 jakob  mem    REG  253,0    103104 6299797 /usr/lib64/libz.so.1.2.11
nano    14682 jakob  mem    REG  253,0   3222128 6293317 /usr/lib64/libc-2.32.so
nano    14682 jakob  mem    REG  253,0    191480 6298831 /usr/lib64/libtinfo.so.6.2
nano    14682 jakob  mem    REG  253,0    263104 6297444 /usr/lib64/libncursesw.so.6.2
nano    14682 jakob  mem    REG  253,0    182576 6309068 /usr/lib64/libmagic.so.1.0.0
nano    14682 jakob  mem    REG  253,0     26998 6817233 /usr/lib64/gconv/gconv-modules.cache
nano    14682 jakob  mem    REG  253,0    264360 6298832 /usr/lib64/ld-2.32.so
nano    14682 jakob    0u   CHR  136,0       0t0       3 /dev/pts/0
nano    14682 jakob    1u   CHR  136,0       0t0       3 /dev/pts/0
nano    14682 jakob    2u   CHR  136,0       0t0       3 /dev/pts/0

What editor do you use? Can you check with lsof if it keeps the file open?

[petrarca-arezzo]

I tried it with a few different editors (nano, xed, emacs, atom). With all of them the directory gets unmounted after the idle-time even though files are in use (open in the editors with unsaved changes made).
Here some results after the gocryptfs-directory is mounted and four files opened in the editors with unsaved changes:

user@linux ~ $ uname -a
Linux linux 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
user@linux ~ $ fusermount -u /home/user/secret 
fusermount: failed to unmount /home/user/secret: Device or resource busy
user@linux ~ $ lsof -p $(pgrep nano) | grep home
nano    33555 user  cwd    DIR   0,55     4096  7004411 /home/user/secret
user@linux ~ $ lsof -p $(pgrep xed) | grep home
xed     33562 user  cwd       DIR               0,60    12288  6946824 /home/user
xed     33562 user  mem       REG               0,60    32768  6961704 /home/user/.local/share/gvfs-metadata/root-199bc02a.log
xed     33562 user  mem       REG               0,60    55476  6947290 /home/user/.local/share/gvfs-metadata/root
xed     33562 user  mem       REG               0,60    86057  6969237 /home/user/.config/dconf/user
xed     33562 user    2w      REG               0,60    25446  6946963 /home/user/.xsession-errors
xed     33562 user   13r      REG               0,60    55476  6947290 /home/user/.local/share/gvfs-metadata/root
xed     33562 user   14r      REG               0,60    32768  6961704 /home/user/.local/share/gvfs-metadata/root-199bc02a.log
user@linux ~ $ lsof -p $(pgrep emacs) | grep home
emacs   33609 user  cwd       DIR               0,55     4096  7004411 /home/user/secret
emacs   33609 user  mem       REG               0,60    86057  6969237 /home/user/.config/dconf/user
emacs   33609 user    2w      REG               0,60    25446  6946963 /home/user/.xsession-errors
user@linux ~ $ lsof -p $(pgrep atom) | grep home
lsof: status error on 33317: No such file or directory
lsof: status error on 33322: No such file or directory
lsof: status error on 33324: No such file or directory
lsof: status error on 33348: No such file or directory
lsof: status error on 33371: No such file or directory
lsof: status error on 33436: No such file or directory
lsof 4.93.2
 latest revision: https://github.com/lsof-org/lsof
 latest FAQ: https://github.com/lsof-org/lsof/blob/master/00FAQ
 latest (non-formatted) man page: https://github.com/lsof-org/lsof/blob/master/Lsof.8
 usage: [-?abhKlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-E] [+|-e s] [+|-f[gG]]
 [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-p s]
 [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names]
Use the ``-h'' option to get more help information.
user@linux ~ $ mount | grep gocryptfs
/home/user/.secret on /home/user/secret type fuse.gocryptfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,max_read=131072)

then after some (idle-) time:

user@linux ~ $ mount | grep gocryptfs
user@linux ~ $ fusermount -u /home/user/secret 
fusermount: entry for /home/user/secret not found in /etc/mtab
user@linux ~ $

It seems that lsof (not working for me with 'atom') is just showing the mounted folder but not the actual file being edited; exception being xed which only shows the home directory under which the gocryptfs-folder is mounted.

I really hope, I'm not doing some dumb here; can someone reproduce (or not) what I'm seeing?

[rfjakob]

Nothing dumb :)

I can reproduce the behavior with nano. But I'm not sure what to do about it, as the file is not actually kept open by nano.

[petrarca-arezzo]

What puzzles me though is that if I open a file (with e.g. nano), I can't unmount the directory manually with fusermount. So it seems that fusermount is somehow recognizing the open file.

The first line of the lsof list shows that the mounted directory is in use (but not the actual file). So one might need to look for the directory being used, and not looking for a file being used (?):

user@linux ~ $ lsof -p $(pgrep nano) | grep home
nano    181767 user  cwd    DIR   0,58     4096  7004411 /home/user/secret
user@linux ~ $ lsof -p $(pgrep nano)
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
nano    181767 user  cwd    DIR   0,58     4096  7004411 /home/user/secret
nano    181767 user  rtd    DIR    8,1     4096        2 /
nano    181767 user  txt    REG    8,1   320136  2359348 /bin/nano
nano    181767 user  mem    REG    8,1    51832 14418433 /lib/x86_64-linux-gnu/libnss_files-2.31.so
nano    181767 user  mem    REG    8,1   105528 14418422 /lib/x86_64-linux-gnu/libnsl-2.31.so
nano    181767 user  mem    REG    8,1    57901 26493553 /usr/share/locale-langpack/de/LC_MESSAGES/nano.mo
nano    181767 user  mem    REG    8,1  6070224 25821215 /usr/lib/locale/locale-archive
nano    181767 user  mem    REG    8,1    18816 14418395 /lib/x86_64-linux-gnu/libdl-2.31.so
nano    181767 user  mem    REG    8,1  2029224 14418369 /lib/x86_64-linux-gnu/libc-2.31.so
nano    181767 user  mem    REG    8,1   192032 14418683 /lib/x86_64-linux-gnu/libtinfo.so.6.2
nano    181767 user  mem    REG    8,1   231504 14418180 /lib/x86_64-linux-gnu/libncursesw.so.6.2
nano    181767 user  mem    REG    8,1    55928 14418435 /lib/x86_64-linux-gnu/libnss_nis-2.31.so
nano    181767 user  mem    REG    8,1    43968 14418426 /lib/x86_64-linux-gnu/libnss_compat-2.31.so
nano    181767 user  mem    REG    8,1    27002 26223849 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
nano    181767 user  mem    REG    8,1   191472 14418270 /lib/x86_64-linux-gnu/ld-2.31.so
nano    181767 user    0u   CHR  136,1      0t0        4 /dev/pts/1
nano    181767 user    1u   CHR  136,1      0t0        4 /dev/pts/1
nano    181767 user    2u   CHR  136,1      0t0        4 /dev/pts/1
user@linux ~ $ fusermount -u secret
fusermount: failed to unmount /home/user/secret: Device or resource busy

[rfjakob]

That is true, however, try this:

cd /
nano /home/user/secret

[rfjakob]

PS: What I will do is to make the idle unmount behave like fusermount -u. That fixes the case:

cd /home/user
nano secret

But not that one:

cd /
nano /home/user/secret

[AltitudeApps]

Hello, I was having a similar problem.

In my case it was a process keypassxc-proxy.exe which remained after quitting KeyPassXC on Windows. (I am using gocryptfs from WSL, but using the mounted filesystem from Windows.)

I am noting it here since this page is what kagi offered as the first link when I searched for failed to unmount /root/gocryptfs-mnt/smallsync/plaintext: Device or resource busy.

Surely I will have this problem again in the future. Maybe someone else will as well, and will benefit from this note.