Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205409 > unrolled thread

Can't scan new disk

Back to article view | Back to linux.debian.user

Contents

  Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-16 00:30 +0100
    Re: Can't scan new disk deb <deb@rangingthoughts.org> - 2019-02-16 01:10 +0100
      Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-16 02:50 +0100
    Re: Can't scan new disk songbird <songbird@anthive.com> - 2019-02-16 01:30 +0100
      Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-16 02:50 +0100
    Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-16 04:20 +0100
      Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-16 21:40 +0100
        Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-16 23:20 +0100
          Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-18 04:20 +0100
            Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-19 00:40 +0100
          Re: Can't scan new disk Celejar <celejar@gmail.com> - 2019-02-19 19:00 +0100
            Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-20 03:50 +0100
              Re: Can't scan new disk Celejar <celejar@gmail.com> - 2019-02-20 04:30 +0100
                Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-20 06:30 +0100
                  Re: Can't scan new disk Celejar <celejar@gmail.com> - 2019-02-20 14:20 +0100
    Re: Can't scan new disk Curt <curty@free.fr> - 2019-02-16 09:50 +0100
      Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-16 21:30 +0100
        Re: Can't scan new disk "Alexander V. Makartsev" <avbetev@gmail.com> - 2019-02-18 06:10 +0100
          Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-20 07:20 +0100
            Re: Can't scan new disk Curt <curty@free.fr> - 2019-02-20 10:30 +0100
              Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-20 10:30 +0100
                Re: Can't scan new disk Curt <curty@free.fr> - 2019-02-20 11:30 +0100
            Re: Can't scan new disk "Alexander V. Makartsev" <avbetev@gmail.com> - 2019-02-20 10:30 +0100
              Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-20 10:50 +0100
                Re: Can't scan new disk "Thomas Schmitt" <scdbackup@gmx.net> - 2019-02-20 11:30 +0100
              Re: Can't scan new disk Curt <curty@free.fr> - 2019-02-20 13:20 +0100
              Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-24 15:50 +0100
                Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-24 21:30 +0100
                  Re: Can't scan new disk David Wright <deblis@lionunicorn.co.uk> - 2019-02-24 23:10 +0100
                    Re: Can't scan new disk David Christensen <dpchrist@holgerdanske.com> - 2019-02-25 01:10 +0100
                    Re: Can't scan new disk Linux-Fan <Ma_Sys.ma@web.de> - 2019-02-25 12:40 +0100
                  Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-25 15:20 +0100
                    Re: Can't scan new disk Curt <curty@free.fr> - 2019-02-25 15:50 +0100
                      Re: Can't scan new disk Mark Allums <mark@allums.email> - 2019-02-25 16:00 +0100
                        Re: Can't scan new disk David Wright <deblis@lionunicorn.co.uk> - 2019-02-25 16:30 +0100
                        Re: Can't scan new disk <tomas@tuxteam.de> - 2019-02-26 09:30 +0100
                Re: Can't scan new disk David Wright <deblis@lionunicorn.co.uk> - 2019-02-24 23:10 +0100
                Re: Can't scan new disk "Alexander V. Makartsev" <avbetev@gmail.com> - 2019-02-25 20:20 +0100
            Re: Can't scan new disk Jude DaShiell <jdashiel@panix.com> - 2019-02-20 18:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#205540

On 2/20/19 3:19 AM, Curt wrote:
> On 2019-02-20, Mark Allums <mark@allums.email> 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:~#
> 
>>From what I'm reading you'll have to be martha for this and not root
> (*une fois n'est pas coutume*), if martha mounted.

martha is the name of the server.


>>From man mount.fuse:
> 
>   SECURITY
>     The fusermount program is installed set-user-gid to fuse. This is done to
>     allow users from  fuse group to mount their own filesystem implementations.
>     There must however be some limitations, in order to prevent Bad User from doing
>     nasty things.  Currently those limitations are:
> 
>     1.     The user can only mount on a mountpoint, for which it has write permission
> 
>     2.     The mountpoint is not a sticky directory which isn't owned by the user (like /tmp usually
>                is)
> 
>     3.     No other user (including root) can access the contents of the mounted filesystem.
> 
> 

The disk is not mounted.

[toc] | [prev] | [next] | [standalone]

#205543

On 2019-02-20, Mark Allums <mark@allums.email> wrote:
> On 2/20/19 3:19 AM, Curt wrote:
>> On 2019-02-20, Mark Allums <mark@allums.email> 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:~#
>> 
>>>From what I'm reading you'll have to be martha for this and not root
>> (*une fois n'est pas coutume*), if martha mounted.
>
> martha is the name of the server.

I said if. Poor martha.  Whoever mounted.
>
>>>From man mount.fuse:
>> 
>>   SECURITY
>>     The fusermount program is installed set-user-gid to fuse. This is done to
>>     allow users from  fuse group to mount their own filesystem implementations.
>>     There must however be some limitations, in order to prevent Bad User from doing
>>     nasty things.  Currently those limitations are:
>> 
>>     1.     The user can only mount on a mountpoint, for which it has write permission
>> 
>>     2.     The mountpoint is not a sticky directory which isn't owned by the user (like /tmp usually
>>                is)
>> 
>>     3.     No other user (including root) can access the contents of the mounted filesystem.
>> 
>> 
>
> The disk is not mounted.

I don't think it matters (as you seem to have demonstrated).



-- 

When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
Jean Rhys, Voyage in the Dark

[toc] | [prev] | [next] | [standalone]

#205539

[Multipart message — attachments visible in raw view] — view raw

On 20.02.2019 11:16, Mark Allums wrote:
> On 2/17/19 10:59 PM, Alexander V. Makartsev wrote:
>> On 17.02.2019 1:21, Mark Allums wrote:
>>> On 2/16/19 2:41 AM, Curt wrote:
>>>> On 2019-02-15, Mark Allums <mark@allums.email> wrote:
>>>>> I just bought a new backup disk, and I want to check it. It's
>>>>> mounted in
>>>>> a USB dock.
>>>>>
>>>>> Running the following gives an error:
>>>>>
>>>>> root@martha:~# umount /dev/sdb1
>>>>> root@martha:~# e2fsck -c -c -C 0 -f -F -k -p /dev/sdb1
>>>>> /dev/sdb1 is in use.
>>>>> e2fsck: Cannot continue, aborting.
>>>>>
>>>>> What's causing this and how do I fix it?  It's not MATE; I tried
>>>>> rebooting to rescue mode, but that didn't help.
>>>>>
>>>>> Mark
>>>>
>>>> People sometimes recommend 'fuser' in cases like these in order to
>>>> identify processes that might be accessing the drive.
>>>>
>>>> I mean, the message says '/dev/sdb1 is in use.' Perhaps it is indeed.
>>>>
>>>>   fuser -v -m /dev/sdb1
>>>>
>>>> Worth a try, maybe, as no one else seems to have suggested it.
>>>
>>> root@martha:~# fuser -v -m /dev/sdb1
>>> root@martha:~#
>>>
>>> No results.  Thanks.
>>>
>>> Mark
>>>
>> 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

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#205541

On 2/20/19 3:20 AM, Alexander V. Makartsev wrote:
> On 20.02.2019 11:16, Mark Allums wrote:
>> On 2/17/19 10:59 PM, Alexander V. Makartsev wrote:
>>> On 17.02.2019 1:21, Mark Allums wrote:
>>>> On 2/16/19 2:41 AM, Curt wrote:
>>>>> On 2019-02-15, Mark Allums <mark@allums.email> wrote:
>>>>>> I just bought a new backup disk, and I want to check it. It's 
>>>>>> mounted in
>>>>>> a USB dock.
>>>>>>
>>>>>> Running the following gives an error:
>>>>>>
>>>>>> root@martha:~# umount /dev/sdb1
>>>>>> root@martha:~# e2fsck -c -c -C 0 -f -F -k -p /dev/sdb1
>>>>>> /dev/sdb1 is in use.
>>>>>> e2fsck: Cannot continue, aborting.
>>>>>>
>>>>>> What's causing this and how do I fix it?  It's not MATE; I tried
>>>>>> rebooting to rescue mode, but that didn't help.
>>>>>>
>>>>>> Mark
>>>>>
>>>>> People sometimes recommend 'fuser' in cases like these in order to
>>>>> identify processes that might be accessing the drive.
>>>>>
>>>>> I mean, the message says '/dev/sdb1 is in use.' Perhaps it is indeed.
>>>>>
>>>>>   fuser -v -m /dev/sdb1
>>>>>
>>>>> Worth a try, maybe, as no one else seems to have suggested it.
>>>>
>>>> root@martha:~# fuser -v -m /dev/sdb1
>>>> root@martha:~#
>>>>
>>>> No results.  Thanks.
>>>>
>>>> Mark
>>>>
>>> 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


The disk is not mounted.

[toc] | [prev] | [next] | [standalone]

#205544

Hi,

Mark Allums wrote:
> The disk is not mounted.

At least not from the perception of e2fsck, indeed, or else it would say
  "%s is mounted.\n"
instead of
  "%s is in use.\n"
See
  https://sources.debian.org/src/e2fsprogs/1.44.5-1/e2fsck/unix.c/?hl=269#L269
(found by
  https://codesearch.debian.net/search?q=package%3Ae2fsprogs+is+in+use
)

If i understand the code correctly, the program gets to that spot because
condition

  if ((!(ctx->mount_flags & (EXT2_MF_MOUNTED | EXT2_MF_BUSY))) ||

is not true. It says "is in use", because

  if (ctx->mount_flags & EXT2_MF_MOUNTED)

is not true. I.e. (ctx->mount_flags & EXT2_MF_BUSY) is true.

I bet that it is about open(2)/fcntl(2) flag O_EXCL, because of
  https://codesearch.debian.net/search?q=package%3Ae2fsprogs+EXT2_MF_BUSY
  https://sources.debian.org/src/e2fsprogs/1.44.5-1/lib/ext2fs/ismounted.c/?hl=415#L410
where i see 

            int fd = open(device, O_RDONLY | O_EXCL);

            if (fd >= 0)
                    close(fd);
            else if (errno == EBUSY)
                    *mount_flags |= EXT2_MF_BUSY;

O_EXCL has a special meaning with Linux device files. It works as advisory
locking with this file type only. In the context of mounting, a failure
with O_EXCL and success without that flag instructs the mounter to mount
read-only. In the context of CD burning, it tells an interested drive
groping program (except mount(8)) to leave the drive alone. Even cdrecord
joined that party.


So one should hop back to the sub-thread where open file pointers to
/dev/sdb1 were the main suspects.

fcntl(2) would be able to inquire the O_EXCL flag by command F_GETFL,
but it needs the file descriptor which is an integer number in the context
of the using process. Dunno whether it is possible to inquire this from
another process.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#205547

On 2019-02-20, Alexander V. Makartsev <avbetev@gmail.com> wrote:
>>
> There you have it. "lsof" command should not output anything if examined
> object is not in use.

I believe you're wrong, at least according my experimentations below.

curty@einstein:~$ mount | grep /dev/sdb1
/dev/sdb1 on /media/76b40b65-5871-4e11-8ed7-64b76e1b4808 type ext2 (rw,nosuid,nodev,noexec,relatime,block_validity,barrier,user_xattr,acl,user)
root@einstein:/home/curty# umount /dev/sdb1
root@einstein:/home/curty# mount | grep /dev/sdb1
root@einstein:/home/curty# 
root@einstein:/home/curty# lsof /dev/sdb1
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
curty@einstein:~$ lsof /dev/sdb1
curty@einstein:~$ 

[toc] | [prev] | [next] | [standalone]

#205729

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

[toc] | [prev] | [next] | [standalone]

#205738

On 2/24/19 6:42 AM, Mark Allums wrote:
> 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?

Use an OS and/or desktop that do not have automatic mounting.  I use 
Debian Stable with Xfce.  One of the first things I do after 
installation is to disable automounting via Thunar (Xfce file manager).


If that does not work, make your own Debian console-only live USB stick 
-- download the latest Debian Stable installer, burn it to media, 
connect a 16+ GB USB 3.0 flash drive, wipe the flash drive, power down, 
completely disconnect all HDD's and SSD's (power and data cables for 
internal drives, USB, Firewire, etc., cables for external drives), leave 
the USB flash drive connected, boot the install media, start the Debian 
installer, install to the USB flash drive, at the "Choose software to 
install" menu select "SSH server" and "standard system utilities" only, 
finish the install, reboot into the USB flash drive, remove the install 
media, SSH in from another machine, connect your USB dock and disk, and 
trouble-shoot.


David

[toc] | [prev] | [next] | [standalone]

#205742

On Sun 24 Feb 2019 at 12:26:25 (-0800), David Christensen wrote:
> 
> If that does not work, make your own Debian console-only live USB
> stick -- download the latest Debian Stable installer, burn it to
> media, connect a 16+ GB USB 3.0 flash drive, wipe the flash drive,
> power down, completely disconnect all HDD's and SSD's (power and data
> cables for internal drives, USB, Firewire, etc., cables for external
> drives), leave the USB flash drive connected, boot the install media,
> start the Debian installer, install to the USB flash drive, at the
> "Choose software to install" menu select "SSH server" and "standard
> system utilities" only, finish the install, reboot into the USB flash
> drive, remove the install media, SSH in from another machine, connect
> your USB dock and disk, and trouble-shoot.

Surely there's a recipe for creating a live USB stick that doesn't
involve tearing out the guts of your PC. What does one do with a laptop?

I realise that leaving things connected probably involves one in a
full round of backup complete with off-site storage. :)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205744

On 2/24/19 2:07 PM, David Wright wrote:
> On Sun 24 Feb 2019 at 12:26:25 (-0800), David Christensen wrote:
>>
>> If that does not work, make your own Debian console-only live USB
>> stick -- download the latest Debian Stable installer, burn it to
>> media, connect a 16+ GB USB 3.0 flash drive, wipe the flash drive,
>> power down, completely disconnect all HDD's and SSD's (power and data
>> cables for internal drives, USB, Firewire, etc., cables for external
>> drives), leave the USB flash drive connected, boot the install media,
>> start the Debian installer, install to the USB flash drive, at the
>> "Choose software to install" menu select "SSH server" and "standard
>> system utilities" only, finish the install, reboot into the USB flash
>> drive, remove the install media, SSH in from another machine, connect
>> your USB dock and disk, and trouble-shoot.
> 
> Surely there's a recipe for creating a live USB stick that doesn't
> involve tearing out the guts of your PC. 

Sure -- leave all the drives connected and don't make any mistakes.


> What does one do with a laptop?

My Dell Inspiron E1505 has an externally-accessible 2.5" x 9 mm SATA 
drive bay -- four screws and the drive slides out.


> I realise that leaving things connected probably involves one in a
> full round of backup complete with off-site storage. :)

Many years ago I bought a large rack-mount ATX case with lots of 
external bays, filled it up with drive docks and HBA's, and started 
collecting HDD's/ SSD's/ USB flash drives -- small ones for various OS's 
and large ones for backups, archives, and images.  Everyone who works on 
computers needs something like this.


The other key asset is a dedicated file server/ version control server.


David

[toc] | [prev] | [next] | [standalone]

#205747

[Multipart message — attachments visible in raw view] — view raw

David Wright writes:

> On Sun 24 Feb 2019 at 12:26:25 (-0800), David Christensen wrote:
> >
> > If that does not work, make your own Debian console-only live USB
> > stick -- download the latest Debian Stable installer, burn it to
> > media, connect a 16+ GB USB 3.0 flash drive, wipe the flash drive,
> > power down, completely disconnect all HDD's and SSD's (power and data
> > cables for internal drives, USB, Firewire, etc., cables for external
> > drives), leave the USB flash drive connected, boot the install media,
> > start the Debian installer, install to the USB flash drive, at the
> > "Choose software to install" menu select "SSH server" and "standard
> > system utilities" only, finish the install, reboot into the USB flash
> > drive, remove the install media, SSH in from another machine, connect
> > your USB dock and disk, and trouble-shoot.
>
> Surely there's a recipe for creating a live USB stick that doesn't
> involve tearing out the guts of your PC. What does one do with a laptop?

Multiple:

 * Do as described above but run the installer in a virtual machine
   and use passthrough for the USB stick (not tested, in case it will
   not work due to the passthrough one can think about creating an
   image inside the VM and writing it to the USB stick outside).

 * Use Debian live-build (although I never got that to work yet)

 * Remastersys (seems to be "Linux Respin" now... I am still using
   an old customized version of mine but newer versions are likely
   to work just as well or better?): This tool creates a live CD image
   out of a running linux system which can be a physical machine, a
   docker (or other but not tested yet :) ) container or a virtual
   machine.

> I realise that leaving things connected probably involves one in a
> full round of backup complete with off-site storage. :)

Backup is never wrong, but I think other approaches to running the installer
on the hardware itself have the additional advantage that the rest of the
system (e-mail, webbrowsing, whatever background services one might run)
need not go offline for the duration of the installation :)

HTH
Linux-Fan

[toc] | [prev] | [next] | [standalone]

#205750

On 2/24/19 2:26 PM, David Christensen wrote:
> On 2/24/19 6:42 AM, Mark Allums wrote:
>> 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?
> 
> Use an OS and/or desktop that do not have automatic mounting.  I use 
> Debian Stable with Xfce.  One of the first things I do after 
> installation is to disable automounting via Thunar (Xfce file manager).
> 
> 
> If that does not work, make your own Debian console-only live USB stick 
> -- download the latest Debian Stable installer, burn it to media, 
> connect a 16+ GB USB 3.0 flash drive, wipe the flash drive, power down, 
> completely disconnect all HDD's and SSD's (power and data cables for 
> internal drives, USB, Firewire, etc., cables for external drives), leave 
> the USB flash drive connected, boot the install media, start the Debian 
> installer, install to the USB flash drive, at the "Choose software to 
> install" menu select "SSH server" and "standard system utilities" only, 
> finish the install, reboot into the USB flash drive, remove the install 
> media, SSH in from another machine, connect your USB dock and disk, and 
> trouble-shoot.
> 
> 
> David
> 

This is not satisfactory.  Surely there is a way to neutralize a running 
gvfsd/fuse mount on a device without reinstalling to whole OS.

Mark

[toc] | [prev] | [next] | [standalone]

#205751

On 2019-02-25, Mark Allums <mark@allums.email> wrote:
>> 
>
> This is not satisfactory.  Surely there is a way to neutralize a running 
> gvfsd/fuse mount on a device without reinstalling to whole OS.
>
> Mark
>

man gvfsd says:

 ENVIRONMENT
       GVFS_DISABLE_FUSE
           If this environment variable is set, gvfsd will not start the fuse filesystem.

So maybe something like

 GVFS_DISABLE_FUSE=1
 export GVFS_DISABLE_FUSE

might be of aid in your neutralization efforts.

Or perhaps simply:

 gconftool --type Boolean --set /apps/nautilus/preferences/media_automount false

If not, sorry, and my respects to Martha.

-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
Jean Rhys, Voyage in the Dark

[toc] | [prev] | [next] | [standalone]

#205752

On 2/25/19 8:48 AM, Curt wrote:
> On 2019-02-25, Mark Allums <mark@allums.email> wrote:
>>>
>>
>> This is not satisfactory.  Surely there is a way to neutralize a running
>> gvfsd/fuse mount on a device without reinstalling to whole OS.
>>
>> Mark
>>
> 
> man gvfsd says:
> 
>   ENVIRONMENT
>         GVFS_DISABLE_FUSE
>             If this environment variable is set, gvfsd will not start the fuse filesystem.
> 
> So maybe something like
> 
>   GVFS_DISABLE_FUSE=1
>   export GVFS_DISABLE_FUSE
> 
> might be of aid in your neutralization efforts.

Doesn't work.


> 
> Or perhaps simply:
> 
>   gconftool --type Boolean --set /apps/nautilus/preferences/media_automount false
> 
> If not, sorry, and my respects to Martha.
> 

I don't use Gnome/Nautilus.  MATE and/or Xfce.

Mark

[toc] | [prev] | [next] | [standalone]

#205753

On Mon 25 Feb 2019 at 08:55:58 (-0600), Mark Allums wrote:
> On 2/25/19 8:48 AM, Curt wrote:
> > On 2019-02-25, Mark Allums <mark@allums.email> wrote:
> > > 
> > > This is not satisfactory.  Surely there is a way to neutralize a running
> > > gvfsd/fuse mount on a device without reinstalling to whole OS.
> > 
> > man gvfsd says:
> > 
> >   ENVIRONMENT
> >         GVFS_DISABLE_FUSE
> >             If this environment variable is set, gvfsd will not start the fuse filesystem.
> > 
> > So maybe something like
> > 
> >   GVFS_DISABLE_FUSE=1
> >   export GVFS_DISABLE_FUSE
> > 
> > might be of aid in your neutralization efforts.
> 
> Doesn't work.

No surprise there then. But when I pointed out this variable
yesterday, I warned that setting this variable so that it
gets noticed might not be straightforward. So writing
"Doesn't work" doesn't really cut it, not to put too fine
a point on it.

And my other suggestion?

> > Or perhaps simply:
> > 
> >   gconftool --type Boolean --set /apps/nautilus/preferences/media_automount false
> > 
> > If not, sorry, and my respects to Martha.
> > 
> 
> I don't use Gnome/Nautilus.  MATE and/or Xfce.

Perhaps booting into single user mode (root) is brutal enough.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205758

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 25, 2019 at 08:55:58AM -0600, Mark Allums wrote:
> On 2/25/19 8:48 AM, Curt wrote:
> >On 2019-02-25, Mark Allums <mark@allums.email> wrote:
> >>>
> >>
> >>This is not satisfactory.  Surely there is a way to neutralize a running
> >>gvfsd/fuse mount on a device without reinstalling to whole OS.
> >>
> >>Mark
> >>
> >
> >man gvfsd says:
> >
> >  ENVIRONMENT
> >        GVFS_DISABLE_FUSE
> >            If this environment variable is set, gvfsd will not start the fuse filesystem.
> >
> >So maybe something like
> >
> >  GVFS_DISABLE_FUSE=1
> >  export GVFS_DISABLE_FUSE
> >
> >might be of aid in your neutralization efforts.
> 
> Doesn't work.

This is a question of context: the above magic incantations should
happen in a place where the gvfsd is capable of inheriting this
environment. Probably at your Gnome session's start, wherever that
is...

[...]

> >  gconftool --type Boolean --set /apps/nautilus/preferences/media_automount false
[...]
> I don't use Gnome/Nautilus.  MATE and/or Xfce.
[...]

...or however that is called under those variants (note that gconftool
probably is relevant to Xfce, it definitely is to MATE -- how the
configuration bit paths are there is left as an exercise to the reader:
shudder: on the one hand people say that editing text config files is
"too hard" for "normal users", on the other hand they dump non-interfaces
on them that are crude key-value databases with an excuse of an editor
(gconf, Mozilla's about:config) bolted on and with an implicit "whack-
the-key" game. But I disgress).

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#205743

On Sun 24 Feb 2019 at 08:42:28 (-0600), 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?

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205755

[Multipart message — attachments visible in raw view] — view raw

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
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#205555

umount /dev/sdb probably will work better.
gparted /dev/sdb also.
if those two don't throw errors, try print command inside gparted and
learn about your new hardware.


--

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web