On 24.02.2019 19:42, Mark Allums wrote: > On 2/20/19 3:20 AM, Alexander V. Makartsev wrote: > >>>> Maybe something simple like "lsof" command can shed some light on >>>> this problem? >>>> $ sudo lsof /dev/sdb >>>> $ sudo lsof /dev/sdb1 >>> >>> root@martha:~# lsof /dev/sdb >>> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >>> /run/user/1001/gvfs >>> Output information may be incomplete. >>> root@martha:~# lsof /dev/sdb1 >>> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >>> /run/user/1001/gvfs >>> Output information may be incomplete. >>> root@martha:~# >>> >> There you have it. "lsof" command should not output anything if >> examined object is not in use. >> I assume that "/dev/sdb1" gets auto-mounted by gvfsd [1] for user >> with UID 1001. >> AFAIK GIO and company implements different mounting scheme without >> involving traditional kernel mounting and allow to restrict mounted >> devices only for user who mounted them. >> So even root user can't access them if they are mounted by other user. >> Try to use gio [2] utility to check status and unmount "/dev/sdb1" >> device. >> >> [1] man gvfsd >> [2] man gio > > I man'ed them, but I got nothing useful for my trouble. How does one > stop gvfsd, or tell it not to mount anything (right now). I'm about > mid-grade with Linux skill, and the care and feeding of demons is a > little above my pay grade. > > root@martha:~# gio mount -u /dev/sdb1 > gio: file:///dev/sdb1: Containing mount for file /dev/sdb1 not found > root@martha:~# gio mount -e /dev/sdb1 > gio: file:///dev/sdb1: Containing mount for file /dev/sdb1 not found > > Any advice as to how to stop the auto-mounter, gvfsd, or fuse, etc. > from tying up my disk, or how to get fsck to scan it? > > Mark > I've tried to reproduce your problem using external USB-SATA adapter (based on JMicron chipset) and working 160Gb HDD, that I dug up from the heap of retired drives. Long story short I wasn't able to reproduce this behavior. There wasn't any interference from kernel\GIO\gvfsd\udisks2\fuse\xfce4-volman\YouNameIt that prevented me from mounting, unmounting, checking filesystem with e2fsck or completely re-creating ext4 filesystem, as long as filesystem wasn't mounted. gvfsd and xfce4-volman were aware that 160Gb drive was connected and icon for it appeared in file manager (Thunar), but they did not prevented me from working with the drive's partition table and filesystems in any way. Kernel was automatically updated about changed partition tables and partitions after gdisk finished its work. Everything was straightforward without having to fiddle with any special commands to control any sub-systems. I've tested this on my main PC with Debian 9 'stretch' and Xfce, which has everything installed to work with all sorts of dynamically mountable hardware from USB thumb drives to cellphones and digital cameras. AFAICR there wasn't anything changed from default settings to get this functionality, only necessary packages were installed from official Debian repos.
At this point I'm guessing that you got a bug that introduces abnormal behavior preventing you from working with the dock and\or large drive and I don't think you can solve it just by typing some commands. Maybe dock's USB-SATA controller is not 100% compatible with Linux and\or has some hardware\firmware quirks that has to be patched up in kernel, etc. You need to test the drive with ordinary SATA connection to be sure it is working fine without USB dock adapter on "martha" host. After that I'd try to test it within Live environment, like SystemRescueCd [1] and try other drive with less capacity (under 2TB) with the same dock on "martha" host. [1] http://www.system-rescue-cd.org/ -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄⠀⠀⠀⠀
