On 2020-02-23, Mark Allums <[email protected]> wrote: > On 2/22/20 8:36 AM, Curt wrote: >> On 2020-02-22, Mark Allums <[email protected]> wrote: >>>> >>>> But does not require superuser, if udisks2 mounted it on your user's >>>> behalf in the first place. >>>> >>>> >>> Explain this, then: >>> >>> george@martha:~$ udisksctl unmount -b /dev/sdb1 >>> Unmounted /dev/sdb1. >>> george@martha:~$ sudo e2fsck -c -c -k -p -f -C 0 /dev/sdb1 >>> /dev/sdb1 is in use. >>> e2fsck: Cannot continue, aborting. >> >> Wasn't it gvfsd the last time? > > I never understood the actual procedure for unmounting when gvfsd was > doing it;s thing, nor how to prevent the whole mess in the first place > (short of doing without gvfsd, et al).
Well, at any rate, I can only believe your deal here (*completely* unrelated to the tool 'undisksctl', BTW, contrary to what some have insinuated) is the exact same deal as the one exposed in the thread you initiated about a year ago https://lists.debian.org/debian-user/2019/02/msg00542.html whose upshot appeared to be root@martha:~# lsof /dev/sdb lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/gvfs Output information may be incomplete. and in which David Wright advised: The man page suggests that running gvfsd --no-fuse or setting a value to GVFS_DISABLE_FUSE will stop it running. How to set an environment variable in a DE is left as an exercise for the reader. > Mark > > -- "J'ai pour me guérir du jugement des autres toute la distance qui me sépare de moi." Antonin Artaud
