Re: partition appears to be mounted, but not according to umount or lsblk

[tomas]

On Fri, Jan 20, 2023 at 09:19:16AM +, thyme after thyme wrote:
> 
> Charles and tomas, you were both right in your guesses. Thanks a billion
> for the help!

Glad you found it :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: partition appears to be mounted, but not according to umount or lsblk

[Cindy Sue Causey]

On 1/20/23, Anssi Saari  wrote:
> Jude DaShiell  writes:
>
>> I wonder if blkid might be a bit more informative.
>
> I don't know, I usually run mount without arguments to see what's
> mounted or look in the file /proc/mounts.


A super simple grep, e.g. "mount|grep sdc", works on it, too. I do it
all the time because it filters out the (visual) noise.

Every since I realized that, my chroot dismounts never fail. Prior to
that, I was having to mostly reboot to dislodge a chroot that had some
or another too "busy" to umount mount point that I couldn't ferret
out.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: partition appears to be mounted, but not according to umount or lsblk

[Anssi Saari]

Jude DaShiell  writes:

> I wonder if blkid might be a bit more informative.

I don't know, I usually run mount without arguments to see what's
mounted or look in the file /proc/mounts.

Re: partition appears to be mounted, but not according to umount or lsblk

[thyme after thyme]

Charles and tomas, you were both right in your guesses. Thanks a billion
for the help!

Re: partition appears to be mounted, but not according to umount or lsblk

[Jude DaShiell]

I wonder if blkid might be a bit more informative.



Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Fri, 20 Jan 2023, to...@tuxteam.de wrote:

> On Thu, Jan 19, 2023 at 11:03:14PM +, thyme after thyme wrote:
> > Hello lovely debianizers,
> >
> > My Debian 10 machine has two physical disks, sda and sdb. The
> > (encrypted) root filesystem is on sdb, meanwhile I?ve used
> > fstab/crypttab to mount an (encrypted) partition on sda to
> > /mnt/data01-hdd, where I?ve stored some stuff:
> >
> > user@hostname:/$ ls -gh /mnt/data01-hdd/
> > total 4.0K
> > drwxr-xr-x 5 1007 4.0K Jan  1 23:02 backups
>
> Perhaps that stuff is just on the directory (using space
> in the partition containing that directory...
>
> > However, when i do
> > user@hostname:/$ sudo umount /mnt/data01-hdd
> >
> > umount complains thus:
> > umount: /mnt/data01-hdd: not mounted.
>
> ...and the partition you think is mounted isn't, after all?
>
> You mount stuff on directories. Those are just plain old directories
> and you can put stuff in them without having anything mounted.
>
> Cheers
>

Re: partition appears to be mounted, but not according to umount or lsblk

[tomas]

On Thu, Jan 19, 2023 at 11:03:14PM +, thyme after thyme wrote:
> Hello lovely debianizers,
> 
> My Debian 10 machine has two physical disks, sda and sdb. The
> (encrypted) root filesystem is on sdb, meanwhile I’ve used
> fstab/crypttab to mount an (encrypted) partition on sda to
> /mnt/data01-hdd, where I’ve stored some stuff:
> 
> user@hostname:/$ ls -gh /mnt/data01-hdd/
> total 4.0K
> drwxr-xr-x 5 1007 4.0K Jan  1 23:02 backups

Perhaps that stuff is just on the directory (using space
in the partition containing that directory...

> However, when i do
> user@hostname:/$ sudo umount /mnt/data01-hdd
> 
> umount complains thus:
> umount: /mnt/data01-hdd: not mounted.

...and the partition you think is mounted isn't, after all?

You mount stuff on directories. Those are just plain old directories
and you can put stuff in them without having anything mounted.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: partition appears to be mounted, but not according to umount or lsblk

[Charles Curley]

On Thu, 19 Jan 2023 23:03:14 +
thyme after thyme  wrote:

> However, when i do
> user@hostname:/$ sudo umount /mnt/data01-hdd
> 
> umount complains thus:
> umount: /mnt/data01-hdd: not mounted.

First off, don't tell us what the program did, show us exactly what the
program did by copying and pasting the initial prompt, the command, and
the following prompt. Like so:

root@ideapc:~# umount /media/disk
umount: /media/disk: not mounted.
root@ideapc:~# 


> 
> How can I unmount the partition?

I haven't seen any evidence that the partition has ever been mounted.
When and how do you think it was mounted, and how do you know? Have you
tried mounting it manually?

Your fstab has the following two (unwrapped) lines:

# 1000gb hdd via its LVM, cf. also /etc/crypttab
#/dev/mapper/1Terabyte01--vg-data01/mnt/data01-hdd ext4 default

That sharp (#) at the beginning of the second line means that line is
commented out. So I suspect the volume never was mounted.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

partition appears to be mounted, but not according to umount or lsblk

[thyme after thyme]

Hello lovely debianizers,

My Debian 10 machine has two physical disks, sda and sdb. The
(encrypted) root filesystem is on sdb, meanwhile I’ve used
fstab/crypttab to mount an (encrypted) partition on sda to
/mnt/data01-hdd, where I’ve stored some stuff:

user@hostname:/$ ls -gh /mnt/data01-hdd/
total 4.0K
drwxr-xr-x 5 1007 4.0K Jan  1 23:02 backups

However, when i do
user@hostname:/$ sudo umount /mnt/data01-hdd

umount complains thus:
umount: /mnt/data01-hdd: not mounted.

How can I unmount the partition?

lsblk -f doesn’t show the partition as mounted, which is something that
I don’t understand:

user@hostname:~$ sudo lsblk -f
NAME FSTYPE  LABEL UUID 
 FSAVAIL FSUSE% MOUNTPOINT  
  
sda
└─sda1   crypto_LUKS  
400a161c-0654-4596-9b1c-3900ef504cb5
  └─sda1_crypt   LVM2_member  
6I1ePw-7IuN-DQqN-02rs-vDgM-e3Nh-DUkfK0
└─1Terabyte01--vg-data01 ext4 
900e8322-5af6-4ecd-827d-fae54f21e4f3
sdb
├─sdb1   ext2 
0791c90e-8567-48c9-90a8-67c7c6619359359.1M18% /boot 

├─sdb2
└─sdb5   crypto_LUKS  
2b5a5240-9d34-42af-958a-a2a4509382d8
  └─sdb5_crypt   LVM2_member  
q9xOdL-yo0s-CDK9-eYiV-0uya-sX7o-WIvPZH
├─debian--vg-rootext4 
4248fdef-e86c-456a-8fc7-2a4ec5b1b0df195.7G52% / 

└─debian--vg-swap_1  swap 
5cc35d37-c746-4bc5-9d00-f437061f6cc8  [SWAP]

The configuration files:

user@hostname:/$ cat /etc/fstab
# /etc/fstab: static file system information.
#
   
/dev/mapper/debian--vg-root   /   ext4   
errors=remount-ro 0   1
# /boot was on /dev/sdb1 during installation
UUID=0791c90e-8567-48c9-90a8-67c7c6619359 /boot   ext2   
defaults  0   2
/dev/mapper/debian--vg-swap_1 noneswapsw
   0   0

# 1000gb hdd via its LVM, cf. also /etc/crypttab
#/dev/mapper/1Terabyte01--vg-data01/mnt/data01-hdd ext4   
default


user@hostname:/$ cat /etc/crypttab
# sdb5 - debian 10 / yunohost on 500Gb HDD
# Tell cryptsetup to create the volume sdb5_crypt from /dev/sdb5
(identified
# by its UUID). Don't use a key file. Since this is the root device, it
will
# automatically be processed during the initramfs stage of boot (making
it
# accessible to dropbear).
#
sdb5_crypt UUID=2b5a5240-9d34-42af-958a-a2a4509382d8 none luks,discard

# sda1 - data on 1000Gb HDD
# Tell cryptsetup to create the volume sda1_crypt from /dev/sda1
(identified
# by its UUID) using the sda1.luks key. Since this is not a root device,
we 
# explicitly require that the device be processed during the initramfs
stage.
#
sda1_crypt UUID=400a161c-0654-4596-9b1c-3900ef504cb5 /etc/keys/sda1.luks
luks,initramfs

I’d much apreciate your guidance!

Thyme Harp

Re: sleep(1) vs. sync(1) twice before umount(8)

[Thomas Schmitt]

Hi,

fxkl4...@protonmail.com wrote:
> > The only reason I ever got was that the second sync was a time delay

The web has it that the time to toggle s-y-n-c-Enter would be enough
to have the first sync succeed.
Another story is that some ancient tape drives (or drivers) rewound the
tape if a second SYNCHRONIZE CACHE command arrived (or some ancestor of
said SCSI command).
I dimly remember a MicroVAX where the shutdown command was: sync;sync;halt

sync;sleep seems to have been necessary with Linux in the previous century.
man 2 sync:

  BUGS
   According to the standard specification  (e.g.,  POSIX.1-2001),  sync()
   schedules the writes, but may return before the actual writing is done.
   However, since version 1.3.20 Linux does actually  wait.   (This  still
   does not guarantee data integrity: modern disks have large caches.)

I had no USB devices back then and always cared to shutdown properly.


David Christensen wrote:
> I sometimes type sync(1) twice when I am
> distracted with several irons in the fire and/or when the system is making
> me worried,

I think one sync per participating device in the dev-mapper stack should be
enough nowadays.

But i would not rely on umount to make a USB stick ready for pulling,
even if experiments show that it happens reliably.
The man pages umount(8) and umount(2) do not guarantee that the device
gets synced. Future programmers might take this as permission to break
things in favor of improved performance.


Have a nice day :)

Thomas

Re: sleep(1) vs. sync(1) twice before umount(8)

[Steve McIntyre]

David wrote:
>On 7/10/22 05:55, fxkl4...@protonmail.com wrote:
> > I'm just flapping my gums
> > As a systems administrator for UNIX systems I wrote more than a few 
>scripts
> > Many time I found it necessary to put a sleep between operations
>
>+1
>
>
>The hard part is deciding what the NUMBER argument should be.  :-/
>
>
> > Several decades ago I was taught to type sync and then type sync 
>again before unmounting a drive
> > The only reason I ever got was that the second sync was a time delay
>
>
>That is an interesting technique.  I sometimes type sync(1) twice when I 
>am distracted with several irons in the fire and/or when the system is 
>making me worried, but it is not my standard practice.
>
>Any potential gotchas?

Sigh, this old canard.

Back in the day (*many* days ago!), the sync was recommended on some
Unix systems as they might *not* necessarily unmount and flush data
cleanly. This has not been necessary since *forever* on any sensible
system, like Linux - the system will already flush all existing
filesystem buffers as part of the umount process.

There *is* one reaonable exception - if you're using dd (or similar)
to write directly to a raw device then that will *not* wait for things
to be flushed *by default*, and may exit cleanly when the kernel still
has buffers outstanding. *Then* you might want to call sync and waif
for that to finish. Or: simply add "oflag=sync" onto your dd call, or
similar.

*Or* you might want to call "sync" in a loop if you're worried you're
about to lose power suddenly. This is what UPSes are for...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: sleep(1) vs. sync(1) twice before umount(8)

[Erwan David]

Le 10/07/2022 à 19:46, fxkl4...@protonmail.com a écrit :

On Sun, 10 Jul 2022, David Christensen wrote:


On 7/10/22 09:57, fxkl4...@protonmail.com wrote:

On Sun, 10 Jul 2022, David Christensen wrote:

On 7/10/22 05:55, fxkl4...@protonmail.com wrote:

Several decades ago I was taught to type sync and then type sync

again before unmounting a drive

The only reason I ever got was that the second sync was a time delay

Any potential gotchas?

I was never brave enough to poke that bear :)


Have you ever experienced any problems or surprises with the technique?

No
I spent a couple of decades baby sitting a room full of HP K200s and K380s
Experimenting was not something done lightly, if you valued your job
You stick with what works
Typing sync twice was advised and I was not inclined to anger some unknown god
Using sleep between operations is as you say experimental
I wrote many scripts that ran as cron jobs at night
I was not concerned with speed
I've been retired for almost a decade and do not miss the sleepless nights


IIRC the second sync() was blocked until the first one finished. Thus 
you were sure to wait the completion of the sync() whereas the sleep()  
waits for a fixed amount of time. However, I'm not sure it is still 
needed with modern file systems

Re: sleep(1) vs. sync(1) twice before umount(8)

[fxkl47BF]

On Sun, 10 Jul 2022, David Christensen wrote:

> On 7/10/22 09:57, fxkl4...@protonmail.com wrote:
>> On Sun, 10 Jul 2022, David Christensen wrote:
>>> On 7/10/22 05:55, fxkl4...@protonmail.com wrote:
>
 Several decades ago I was taught to type sync and then type sync
>>> again before unmounting a drive
 The only reason I ever got was that the second sync was a time delay
>
>>> Any potential gotchas?
>>
>> I was never brave enough to poke that bear :)
>
>
> Have you ever experienced any problems or surprises with the technique?

No
I spent a couple of decades baby sitting a room full of HP K200s and K380s
Experimenting was not something done lightly, if you valued your job
You stick with what works
Typing sync twice was advised and I was not inclined to anger some unknown god
Using sleep between operations is as you say experimental
I wrote many scripts that ran as cron jobs at night
I was not concerned with speed
I've been retired for almost a decade and do not miss the sleepless nights

Re: sleep(1) vs. sync(1) twice before umount(8)

[David Christensen]

On 7/10/22 09:57, fxkl4...@protonmail.com wrote:

On Sun, 10 Jul 2022, David Christensen wrote:

On 7/10/22 05:55, fxkl4...@protonmail.com wrote:



Several decades ago I was taught to type sync and then type sync

again before unmounting a drive

The only reason I ever got was that the second sync was a time delay



Any potential gotchas?


I was never brave enough to poke that bear :)



Have you ever experienced any problems or surprises with the technique?


David

Re: sleep(1) vs. sync(1) twice before umount(8)

[fxkl47BF]

On Sun, 10 Jul 2022, David Christensen wrote:

> On 7/10/22 05:55, fxkl4...@protonmail.com wrote:
> > I'm just flapping my gums
> > As a systems administrator for UNIX systems I wrote more than a few
> scripts
> > Many time I found it necessary to put a sleep between operations
>
> +1
>
>
> The hard part is deciding what the NUMBER argument should be.  :-/
>
>
> > Several decades ago I was taught to type sync and then type sync
> again before unmounting a drive
> > The only reason I ever got was that the second sync was a time delay
>
>
> That is an interesting technique.  I sometimes type sync(1) twice when I
> am distracted with several irons in the fire and/or when the system is
> making me worried, but it is not my standard practice.
>
>
> Any potential gotchas?

I was never brave enough to poke that bear :)

sleep(1) vs. sync(1) twice before umount(8)

[David Christensen]

On 7/10/22 05:55, fxkl4...@protonmail.com wrote:
> I'm just flapping my gums
> As a systems administrator for UNIX systems I wrote more than a few 
scripts

> Many time I found it necessary to put a sleep between operations

+1


The hard part is deciding what the NUMBER argument should be.  :-/


> Several decades ago I was taught to type sync and then type sync 
again before unmounting a drive

> The only reason I ever got was that the second sync was a time delay


That is an interesting technique.  I sometimes type sync(1) twice when I 
am distracted with several irons in the fire and/or when the system is 
making me worried, but it is not my standard practice.



Any potential gotchas?


David

Re: Modern automounters and umount

[Thomas Schmitt]

Hi,

G.W. Haywood wrote:
> The system load averages are elevated to an extent,
> but 'top' doesn't show any particular processes hogging CPU.

If top does not show processes which cause visible high overall CPU load,
then this might indicate many short running processes.

You could estimate the number of processes created in a second by a
bash run like

  ( echo $BASHPID ) ; sleep 1 ; ( echo $BASHPID )

which gives me e.g.

  4482
  4485

and thus indicates that my machine does not busily fork processes.


> Intel E3815

A single core CPU. That's unusual in our time.


Have a nice day :)

Thomas

Re: Modern automounters and umount

[songbird]

Mark Allums wrote:
...
> /usr/lib/gvfs/gvfsd --no-fuse
> Failed to acquire daemon name, perhaps the VFS daemon is already running?

  you sound about as frustrated by this sort of thing as i
was.

  you could try to find out what it is via the gio command
that is being captured and put it in your .bashrc to let it
go when the desktop opens your terminals (i have them saved
as i like them when i'm working on projects so they are 
always here when i boot up the machine).  you can run tty
in each terminal to find out which is the first one and even
use that in your script to only run it the one time.

  the problem i have is when i plug in devices that the
desktop captures even when i tell it to not do anything.
i'm not even sure if this is still a problem or not, but
between udev/udisk2 and gvfs/gio i threw enough hammers
at it all in my script that i got it to go away so it
could then be properly remounted when and where i want it.
you're welcome to take this script and adapt it for your
own uses:

  https://github.com/flowerbug/camera_file

  comments always appreciated.


  songbird

Re: Modern automounters and umount

[Curt]

On 2020-02-25, Mark Allums  wrote:
>> 
>> A tricky exercise which can depend on your DE (and maybe even your
>> graphical login manager). What have you tried so far?
>
> The things I tried are naive.  I don't know, or have forgotten, where to 
> put commands that run that early in the process.  I run the latest MATE 
> out of Bullseye, 1.24.x-y.  There is a partial installation (a 
> "minimal") Gnome 3 installed, and various Gnome-related programs.  XCFE 
> is installed, for emergencies.  (I am a bad typist, and am rather 
> dependent on GUIs.)  I load MATE by default at startup.
>
> /usr/lib/gvfs/gvfsd --no-fuse
> Failed to acquire daemon name, perhaps the VFS daemon is already running?
>

 killall gvfsd
 /usr/lib/gvfs/gvfsd --no-fuse &

might do it (for some arbitrary definition of "it"), but IMO you should search
engine around and experiment with setting the environment variable mentioned
previously).





-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[Jonathan Dowland]

On Mon, Feb 24, 2020 at 04:35:32AM -0600, Mark Allums wrote:

On 2/23/20 3:02 PM, Jonathan Dowland wrote:

Can you repeat this, but include the output of "grep sdb1 /proc/mounts"
before the udisksctl invocation, and again after it?


Thanks.


george@martha:~$ grep sdb1 /proc/mounts
/dev/sdb1 /media/george/5913b3d0-eae1-4748-9ce2-d64d4eb21135 ext4 
rw,sync,nosuid,nodev,relatime 0 0

george@martha:~$ udisksctl unmount -b /dev/sdb1
Unmounted /dev/sdb1.
george@martha:~$ grep sdb1 /proc/mounts



This shows that the partition was mounted prior to invoking udisksctl
and not afterwards. So udisksctl is doing what it is supposed to.

Your problem which seems orthogonal to udisksctl seems to be better
diagnosed in the sub-thread Curt is participating in. Good luck!

--
  Jonathan Dowland
   https://jmtd.net

Re: Modern automounters and umount

[Mark Allums]

On 2/25/20 3:43 AM, Curt wrote:

On 2020-02-25, Mark Allums  wrote:


george@martha:~$ systemctl stop gvfs-daemon
Failed to stop gvfs-daemon.service: Unit gvfs-daemon.service not loaded.


You cannot stop what does not exist.

I think the systemd unit involved is
  
  run-user-1000-gvfs.mount


Try 'systemctl status run-user-1000-gvfs.mount'
and see.


george@martha:~$ systemctl status run-user-1000-gvfs.mount
Unit run-user-1000-gvfs.mount could not be found.



george@martha:~$ gvfsd-fuse
bash: gvfsd-fuse: command not found


This thing isn't in your path, which has been explained.

  /usr/lib/gvfs/gvfsd-fuse


george@martha:~$ man gvfs-fuse
No manual entry for gvfs-fuse


It's called 'gvfsd-fuse'.
GVFSD-FUSE(1)User Commands 
GVFSD-FUSE(1)


NAME
   gvfsd-fuse - Fuse daemon for gvfs

SYNOPSIS
   gvfsd-fuse PATH

DESCRIPTION
   gvfsd-fuse maintains a fuse mount to make gvfs backends available to
   POSIX applications. The mount point for the fuse filesystem is 
provided

   by the [PATH] argument.

   gvfsd-fuse is normally started by gvfsd(1). In this case, the mount
   point is $XDG_RUNTIME_DIR/gvfs or $HOME/.gvfs.

OPTIONS
   -d
   Enable fuse debug output. This implies -f.

   -f
   Run in the foreground.

   -s
   Run single-threaded.

   -o OPTION
   Set a fuse-specific option. See the fuse documentation for a 
list

   of these.

EXIT STATUS
   On success 0 is returned, a non-zero failure code otherwise.

SEE ALSO
   gvfs(7)

gvfs 
GVFSD-FUSE(1)





Please advise as to the best way to set an environment variable on
startup before gvfs, et al load.


A tricky exercise which can depend on your DE (and maybe even your
graphical login manager). What have you tried so far?


The things I tried are naive.  I don't know, or have forgotten, where to 
put commands that run that early in the process.  I run the latest MATE 
out of Bullseye, 1.24.x-y.  There is a partial installation (a 
"minimal") Gnome 3 installed, and various Gnome-related programs.  XCFE 
is installed, for emergencies.  (I am a bad typist, and am rather 
dependent on GUIs.)  I load MATE by default at startup.


/usr/lib/gvfs/gvfsd --no-fuse
Failed to acquire daemon name, perhaps the VFS daemon is already running?

Re: Modern automounters and umount

[Curt]

On 2020-02-25, Mark Allums  wrote:
>
> george@martha:~$ systemctl stop gvfs-daemon
> Failed to stop gvfs-daemon.service: Unit gvfs-daemon.service not loaded.

You cannot stop what does not exist.

I think the systemd unit involved is
 
 run-user-1000-gvfs.mount

Try 'systemctl status run-user-1000-gvfs.mount'
and see.

> george@martha:~$ gvfsd-fuse
> bash: gvfsd-fuse: command not found

This thing isn't in your path, which has been explained.

 /usr/lib/gvfs/gvfsd-fuse

> george@martha:~$ man gvfs-fuse
> No manual entry for gvfs-fuse

It's called 'gvfsd-fuse'.

> Please advise as to the best way to set an environment variable on 
> startup before gvfs, et al load.

A tricky exercise which can depend on your DE (and maybe even your
graphical login manager). What have you tried so far?

> Mark
>
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[Mark Allums]

On 2/24/20 10:08 AM, David Wright wrote:

On Mon 24 Feb 2020 at 10:54:28 (-), Curt wrote:

On 2020-02-24, Mark Allums  wrote:




george@martha:~$ gvfsd --no-fuse
bash: gvfsd: command not found
george@martha:~$ systemctl stop gvfsd
Failed to stop gvfsd.service: Unit gvfsd.service not loaded.

which suggests a bit of misunderstanding about what gvfsd is.
AIUI it's a daemon (hence the d), and not in anyone's PATH,
which is why you have to find out where it's running from and
what might be consulting the value of GVFS_DISABLE_FUSE.
Also I think the service is called gvfs-daemon (but there may
be other related ones involved).


george@martha:~$ systemctl stop gvfs-daemon
Failed to stop gvfs-daemon.service: Unit gvfs-daemon.service not loaded.
george@martha:~$ gvfsd-fuse
bash: gvfsd-fuse: command not found
george@martha:~$ man gvfs-fuse
No manual entry for gvfs-fuse



george@martha:~$ apropos gvfs
gvfs (7) - GIO virtual file system
gvfs-cat (1) - (unknown subject)
gvfs-copy (1)- (unknown subject)
gvfs-info (1)- (unknown subject)
gvfs-less (1)- Execute less on the output of gvfs-cat
gvfs-ls (1)  - (unknown subject)
gvfs-mime (1)- (unknown subject)
gvfs-mkdir (1)   - (unknown subject)
gvfs-monitor-dir (1) - (unknown subject)
gvfs-monitor-file (1) - (unknown subject)
gvfs-mount (1)   - (unknown subject)
gvfs-move (1)- (unknown subject)
gvfs-open (1)- (unknown subject)
gvfs-rename (1)  - (unknown subject)
gvfs-rm (1)  - (unknown subject)
gvfs-save (1)- (unknown subject)
gvfs-set-attribute (1) - (unknown subject)
gvfs-trash (1)   - (unknown subject)
gvfs-tree (1)- (unknown subject)
gvfsd (1)- Main daemon for gvfs
gvfsd-fuse (1)   - Fuse daemon for gvfs
gvfsd-metadata (1)   - Metadata daemon for gvfs




As for doing exercises, I don't have gvfs* installed, nor any DE,
so I wouldn't know where to start.

Drifting a litle, I do remember being surprised how easy it is for
devices to be mounted twice, having had difficulty myself (mount
would complain the device was already mounted). It turned out that,
because the device I tried using was originally mounted readonly,
I also had to set  ro  in the second mount command for it to succeed.

Cheers,
David.



Please advise as to the best way to set an environment variable on 
startup before gvfs, et al load.


Mark

Re: Modern automounters and umount

[Curt]

On 2020-02-24, David Wright  wrote:
>
>
> which suggests a bit of misunderstanding about what gvfsd is.
> AIUI it's a daemon (hence the d), and not in anyone's PATH,
> which is why you have to find out where it's running from and
> what might be consulting the value of GVFS_DISABLE_FUSE.
> Also I think the service is called gvfs-daemon (but there may
> be other related ones involved).

It seems to run from '/usr/lib/gvfs/gvfsd'. 

I don't know whether he tried, simply, "export GVFS_DISABLE_FUSE=1" or
not (and stopped and restarted the daemon by one of the usual methods);
I understood what might consult the value of GVFS_DISABLE_FUSE is the
gvfsd daemon itself.

>From the man:

 gvfsd-fuse is normally started by gvfsd(1). In this case, the mount
 point is $XDG_RUNTIME_DIR/gvfs or $HOME/.gvfs.  

> As for doing exercises, I don't have gvfs* installed, nor any DE,
> so I wouldn't know where to start.
>
> Drifting a litle, I do remember being surprised how easy it is for
> devices to be mounted twice, having had difficulty myself (mount
> would complain the device was already mounted). It turned out that,
> because the device I tried using was originally mounted readonly,
> I also had to set  ro  in the second mount command for it to succeed.
>
> Cheers,
> David.
>
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[David Wright]

On Mon 24 Feb 2020 at 10:54:28 (-), Curt wrote:
> On 2020-02-24, Mark Allums  wrote:
> >>
> >>   How to set an environment variable in a DE is left as an exercise for
> >>   the reader.
> >
> > The gvfsd --no-fuse doesn't do it for me.
> >
> 
> That may be David's exercise then.

I think not. I made my suggestion (exactly a year ago) as I thought
the option, and its corresponding variable, could have been overlooked
on the man page, which was supposed to have been consulted already.

I also wrote on the next day that "Doesn't work" wasn't a response
that carried much information. It's therefore disappointing to read
"doesn't do it for me" this time around.

However, a later post contains:

   george@martha:~$ gvfsd --no-fuse
   bash: gvfsd: command not found
   george@martha:~$ systemctl stop gvfsd
   Failed to stop gvfsd.service: Unit gvfsd.service not loaded.

which suggests a bit of misunderstanding about what gvfsd is.
AIUI it's a daemon (hence the d), and not in anyone's PATH,
which is why you have to find out where it's running from and
what might be consulting the value of GVFS_DISABLE_FUSE.
Also I think the service is called gvfs-daemon (but there may
be other related ones involved).

As for doing exercises, I don't have gvfs* installed, nor any DE,
so I wouldn't know where to start.

Drifting a litle, I do remember being surprised how easy it is for
devices to be mounted twice, having had difficulty myself (mount
would complain the device was already mounted). It turned out that,
because the device I tried using was originally mounted readonly,
I also had to set  ro  in the second mount command for it to succeed.

Cheers,
David.

Re: Modern automounters and umount

[Curt]

On 2020-02-24, Mark Allums  wrote:
>>
>>   How to set an environment variable in a DE is left as an exercise for
>>   the reader.
>
> The gvfsd --no-fuse doesn't do it for me.
>

That may be David's exercise then.

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[Mark Allums]

On 2/23/20 3:02 PM, Jonathan Dowland wrote:

On Fri, Feb 21, 2020 at 09:58:10PM -0600, Mark Allums wrote:

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.


Can you repeat this, but include the output of "grep sdb1 /proc/mounts"
before the udisksctl invocation, and again after it?



george@martha:~$ grep sdb1 /proc/mounts
/dev/sdb1 /media/george/5913b3d0-eae1-4748-9ce2-d64d4eb21135 ext4 
rw,sync,nosuid,nodev,relatime 0 0

george@martha:~$ udisksctl unmount -b /dev/sdb1
Unmounted /dev/sdb1.
george@martha:~$ grep sdb1 /proc/mounts
george@martha:~$ sudo e2fsck -cckp -f -C 0 /dev/sdb1
/dev/sdb1 is in use.
e2fsck: Cannot continue, aborting.


george@martha:~$ gvfsd --no-fuse
bash: gvfsd: command not found
george@martha:~$ systemctl stop gvfsd
Failed to stop gvfsd.service: Unit gvfsd.service not loaded.
george@martha:~$

Re: Modern automounters and umount

[Mark Allums]

On 2/23/20 5:00 AM, Curt wrote:

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.


The gvfsd --no-fuse doesn't do it for me.

Re: Modern automounters and umount

[Thomas Schmitt]

Hi,

  udisksctl -b unmount /dev/sr0
seems to work for the user who has problems with sudo umount.
I write "seems" because feedback is still a bit sparse.

Unmounting by directory name turned out to be too much prone to user
error. I am not sure whether it would work on that system.


Have a nice day :)

Thomas

Re: Modern automounters and umount

[Jonathan Dowland]

On Fri, Feb 21, 2020 at 09:58:10PM -0600, Mark Allums wrote:

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.


Can you repeat this, but include the output of "grep sdb1 /proc/mounts"
before the udisksctl invocation, and again after it?

Re: Modern automounters and umount

[Curt]

On 2020-02-23, Mark Allums  wrote:
> On 2/22/20 8:36 AM, Curt wrote:
>> On 2020-02-22, Mark Allums  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

Re: Modern automounters and umount

[Mark Allums]

On 2/22/20 8:36 AM, Curt wrote:

On 2020-02-22, Mark Allums  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).


Mark

Re: Modern automounters and umount

[Gene Heskett]

On Saturday 22 February 2020 14:55:45 to...@tuxteam.de wrote:

> On Sat, Feb 22, 2020 at 01:22:38PM -0500, Gene Heskett wrote:
>
> [...]
>
> > I dunno, I've got years on you, and I'm not half done with what I
> > need to do yet.
>
> If everything's done before one leaves, then it gets boring, doesn't
> it?
>
OTOH, if you are done, just let it happen. My parts list is beginning to 
look like the 6 million dollar man from b tv days. But I still have a 
missus dying of COPD I'm doing everything for these days.  Something 
about "till death do you part". She turned 80 4 days ago and we marked 
30 years back in December. Still a good girl, what I call a keeper.

> > What I like to find is a government that uses our Constitution, and
> > obeys it! Ours is hell bent on throwing away the bill of rights.
>
> Here hoping for the best!
>
> Cheers
> -- t


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Modern automounters and umount

[tomas]

On Sat, Feb 22, 2020 at 01:22:38PM -0500, Gene Heskett wrote:

[...]

> I dunno, I've got years on you, and I'm not half done with what I need to 
> do yet.

If everything's done before one leaves, then it gets boring, doesn't it?

> What I like to find is a government that uses our Constitution, and obeys 
> it! Ours is hell bent on throwing away the bill of rights.

Here hoping for the best!

Cheers
-- t


signature.asc
Description: Digital signature

Re: Modern automounters and umount

[Gene Heskett]

On Saturday 22 February 2020 12:03:41 to...@tuxteam.de wrote:

> On Sat, Feb 22, 2020 at 05:53:07PM +0100, Thomas Schmitt wrote:
> > Hi,
> >
> > to...@tuxteam.de wrote:
> > > but udisksctl (or however it's called) said "all is well",
> > > so it must be either lying -- or someone else quicly mounted
> > > things after that.
> >
> > There is obvious need for a special distro for age-wise challenged
> > people like me. Or at least some online AI which navigates us
> > through this ever changing IT world.
>
> I still hold the hope to leave this planet before things get too
> messy for me to handle...
>
> Cheers
> -- t
I dunno, I've got years on you, and I'm not half done with what I need to 
do yet.

What I like to find is a government that uses our Constitution, and obeys 
it! Ours is hell bent on throwing away the bill of rights.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Modern automounters and umount

[tomas]

On Sat, Feb 22, 2020 at 05:53:07PM +0100, Thomas Schmitt wrote:
> Hi,
> 
> to...@tuxteam.de wrote:
> > but udisksctl (or however it's called) said "all is well",
> > so it must be either lying -- or someone else quicly mounted
> > things after that.
> 
> There is obvious need for a special distro for age-wise challenged
> people like me. Or at least some online AI which navigates us through
> this ever changing IT world.

I still hold the hope to leave this planet before things get too
messy for me to handle...

Cheers
-- t


signature.asc
Description: Digital signature

Re: Modern automounters and umount

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> but udisksctl (or however it's called) said "all is well",
> so it must be either lying -- or someone else quicly mounted
> things after that.

There is obvious need for a special distro for age-wise challenged
people like me. Or at least some online AI which navigates us through
this ever changing IT world.


Have a nice day :)

Thomas

Re: Modern automounters and umount

[tomas]

On Sat, Feb 22, 2020 at 05:39:00PM +0100, Thomas Schmitt wrote:
> Hi,
> 
> Stefan Monnier wrote:
> > > Or the /dev/sdb1 is still mounted elsewhere.
> 
> to...@tuxteam.de wrote:
> > twice? (it was just umounted once, [...]
> 
> Own experience with Debian 10.0 Live:
> There are two mount points of /dev/sda1 reported.
> The mount point
>   /usr/lib/live/mount/medium
> can be unmounted.
> The mount point
>   /run/live/medium
> refuses to unmount because busy.

Yes, but udisksctl (or however it's called) said "all is well",
so it must be either lying -- or someone else quicly mounted
things after that.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Modern automounters and umount

[Thomas Schmitt]

Hi,

Stefan Monnier wrote:
> > Or the /dev/sdb1 is still mounted elsewhere.

to...@tuxteam.de wrote:
> twice? (it was just umounted once, [...]

Own experience with Debian 10.0 Live:
There are two mount points of /dev/sda1 reported.
The mount point
  /usr/lib/live/mount/medium
can be unmounted.
The mount point
  /run/live/medium
refuses to unmount because busy.

Sorry for not being able yet to provide feedback to the proposals.
I forwarded to my user:
  sudo umount /media/ddval/ISOIMAGE
  pumount /dev/sr0
  pumount /media/ddval/ISOIMAGE
  sudo udisksctl unmount -b /dev/sr0


Have a nice day :)

Thomas

Re: Modern automounters and umount

[tomas]

On Sat, Feb 22, 2020 at 09:29:51AM -0500, Stefan Monnier wrote:
> > So either "udisksctl" is lying or something else is happening
> > behind the scenes (e.g. an over-eager automounter remounting
> > the file system again).
> 
> Or the /dev/sdb1 is still mounted elsewhere.

twice? (it was just umounted once, at least that's what udisksctl
reportedly said).

Cheers
-- t


signature.asc
Description: Digital signature

Re: Modern automounters and umount

[Curt]

On 2020-02-22, Mark Allums  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?

> Thnx,
>
> Mark
>
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[Stefan Monnier]

> So either "udisksctl" is lying or something else is happening
> behind the scenes (e.g. an over-eager automounter remounting
> the file system again).

Or the /dev/sdb1 is still mounted elsewhere.


Stefan

Re: Modern automounters and umount

[tomas]

On Fri, Feb 21, 2020 at 11:47:22PM -0500, Gene Heskett wrote:
> On Friday 21 February 2020 22:58:10 Mark Allums wrote:

[...]

> > 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.
> >
> > Thnx,
> >
> > Mark
> Is there a user cd'd into it?  That locks it up.

You are confusing device file with (mounted) file system.
You can't "cd" into a device file (/dev/sb1), only into
a directory, which is part of a mounted file system. Then,
this directory is "in use". But then you can't umount the
corresponding file system.

So either "udisksctl" is lying or something else is happening
behind the scenes (e.g. an over-eager automounter remounting
the file system again).

I'd watch the logs for more info.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Modern automounters and umount

[Curt]

On 2020-02-22, Gene Heskett  wrote:
>>
>> 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.
>>
>> Thnx,
>>
>> Mark
> Is there a user cd'd into it?  That locks it up.

This is a sane feature.

> Cheers, Gene Heskett


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Modern automounters and umount

[Gene Heskett]

On Friday 21 February 2020 22:58:10 Mark Allums wrote:

> On 2/21/20 9:23 AM, Jonathan Dowland wrote:
> > On Fri, Feb 21, 2020 at 08:53:50AM -0500, Stefan Monnier wrote:
> >> Indeed.  And FWIW, you should/might be able to avoid the `sudo` by
> >> asking udisks2 to do the unmount
> >
> > Yep. It requires you to specify the device, rather than the
> > filesystem mount point:
> >
> >     $ udisksctl unmount -b /dev/sdb1
> >
> > 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.
>
> Thnx,
>
> Mark
Is there a user cd'd into it?  That locks it up.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Modern automounters and umount

[Mark Allums]

On 2/21/20 9:23 AM, Jonathan Dowland wrote:

On Fri, Feb 21, 2020 at 08:53:50AM -0500, Stefan Monnier wrote:

Indeed.  And FWIW, you should/might be able to avoid the `sudo` by
asking udisks2 to do the unmount


Yep. It requires you to specify the device, rather than the filesystem
mount point:

    $ udisksctl unmount -b /dev/sdb1

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.

Thnx,

Mark

Re: Modern automounters and umount

[songbird]

Thomas Schmitt wrote:
...
> Does anybody here experience similar stubbornness of automounting ?
> If so: How to unmount a DVD without ejecting it ?

  not having done much with DVDs recently i can't say much
about them.  i can say that i really hate having something 
automounted even when i tell the system to not do anything 
with it.

  i've not had a chance to test the recent MATE update to 
see if that is still an issue or not, but it sure did get 
my peeve up.

  my camera was being captured by gio or some other part of 
the desktop and i had ticked all the boxes and options to 
tell the desktop that i didn't want it touched at all when 
i plugged it in.

  in my script i have to do some fiddling around to make 
sure the device is unmounted and then remounted where i want
it (and that it is actually available).  i did get the 
script working and that is where it has to sit for now.  :)

  check to see if some desktop or other system widget has got 
ahold of it (udev, gio, gvfs, udisk2 and no, i don't know all 
other possible names or details about things that might be 
doing this sort of interference).

  good luck!


  songbird

Re: Modern automounters and umount

[Jonathan Dowland]

On Fri, Feb 21, 2020 at 08:53:50AM -0500, Stefan Monnier wrote:

Indeed.  And FWIW, you should/might be able to avoid the `sudo` by
asking udisks2 to do the unmount


Yep. It requires you to specify the device, rather than the filesystem
mount point:

   $ udisksctl unmount -b /dev/sdb1

But does not require superuser, if udisks2 mounted it on your user's
behalf in the first place.


--
  Jonathan Dowland
   https://jmtd.net

Re: Modern automounters and umount

[Stefan Monnier]

>> > $ mount | fgrep /dev/sr0
>> > /dev/sr0 on /media/ddval/ISOIMAGE type iso9660 (ro,nosuid,nodev,relatime,
>> > nojoliet,check=s,map=n, blocksize=2048,uid=1000,gid=1000,dmode=500,
>> > fmode=400,uhelper=udisks2)
>> > $ sudo umount /dev/sr0
>> > umount: /dev/sr0: not mounted
> Try instead: sudo umount /media/ddval/ISOIMAGE

Indeed.  And FWIW, you should/might be able to avoid the `sudo` by
asking udisks2 to do the unmount (I don't know how that works, tho.
I personally still use `mount` instead, so I'd do `pumount
/media/ddval/ISOIMAGE`).


Stefan

Re: Modern automounters and umount

[Klaus Singvogel]

Thomas Schmitt wrote:
> > $ mount | fgrep /dev/sr0
> > /dev/sr0 on /media/ddval/ISOIMAGE type iso9660 (ro,nosuid,nodev,relatime,
> > nojoliet,check=s,map=n, blocksize=2048,uid=1000,gid=1000,dmode=500,
> > fmode=400,uhelper=udisks2)
> > $ sudo umount /dev/sr0
> > umount: /dev/sr0: not mounted

Try instead: sudo umount /media/ddval/ISOIMAGE

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Modern automounters and umount

[Thomas Schmitt]

Hi,

during a discussion on linuxquestion.org i got a (Mint) user's report
that an automounted DVD cannot be unmounted manually:

https://www.linuxquestions.org/questions/linux-general-1/compiling-xfburn-source-code-additional-packages-required-4175667265/page7.html#post6092450
> $ mount | fgrep /dev/sr0
> /dev/sr0 on /media/ddval/ISOIMAGE type iso9660 (ro,nosuid,nodev,relatime,
> nojoliet,check=s,map=n, blocksize=2048,uid=1000,gid=1000,dmode=500,
> fmode=400,uhelper=udisks2)
> $ sudo umount /dev/sr0
> umount: /dev/sr0: not mounted

Does anybody here experience similar stubbornness of automounting ?
If so: How to unmount a DVD without ejecting it ?


Have a nice day :)

Thomas

Re: A Very Bad umount

[Rick Thomas]

On Sep 11, 2018, at 12:28 PM, Martin McCormick  wrote:

> /bin/rm: cannot remove 
> '/var/cache/rsnapshot/halfday.1/wb5agz/home/usr/lib/i386
> -linux-gnu': Transport endpoint is not connected

In your rsnapshot.conf file, is “use_lazy_deletes” set to 1?  If so, the final 
delete part of “rsnapshot hourly” may still be going on when you do the unmount.

Just a thought…
Rick 

Re: A Very Bad umount

[Martin McCormick]

=?UTF-8?Q?=c3=89tienne_Mollier?=  writes:
> 
> Good Day,
> 
> Not sure if that is the kind of answer you would wish to
> expect, but have you considered doing umounts sequentially?
> (optionally after synchronizing file systems)
> 
>     sync
> umount /var/cache/rsnapshot
> umount /rsnapshot2
> umount /rsnapshot1
> 
> Each call is blocking, so it will help perhaps...

It has been exactly 2 weeks since I tried your suggestion
and there has not been one backup failure.  It may be too early
to celebrate but the sequencial approach appears to have solved
the problem.

Thank you for your help.

Martin McCormick

Re: A Very Bad umount

[Martin McCormick]

=?UTF-8?Q?=c3=89tienne_Mollier?=  writes:
> Good Day Gene,
> 
> Gene Heskett  2018-09-12T03:14 +0200 :

> 
> Should a badly placed “rm” command occur on the system, the
> system and both of its backup disks would be wiped clean.  I
> don't believe the risk mentioned here over was related to disk
> decay.  It was more about minimizing the time frame when this
> catastrophe could happen.

Precisely. I don't want to leave them mounted since we
might get a power hit that would corrupt the drives causing all
the backups to go poof!

Bad stuff can even happen with good UPS's in line.

When I was a systems engineer at Oklahoma State
University, we had a weird chain of events one cold and bright
Winter day just before Christmas in the mid nineties.

A pigeon wandered in to a power sub station and pecked at
the wrong thing and received about 100-thousand volts through his
body, ruining his day for sure.  The power on the campus went
dark and our UPS's held until an auxiliary generator came on line
a few minutes later.  The problem was that it was running at the
wrong throttle setting, sending AC at near 50 HZ instead of 60 HZ
into our building.  The UPS's were older fero-resonant devices
and the frequency was far enough off that the UPS's stayed
switched to battery mode, something we were unaware of.

About half an hour later, the batteries ran all the way
down and those computers connected to them suddenly lost power
without a proper shut-down.

I think they came back okay but we were just lucky.

Nothing sounds more odd than hearing all the electric
motors and fans in the building revving up and slowing down as
the generator throttle was adjusted to 60 HZ.

The usb drives I am using for backups are SSD devices so
there are no moving parts.

Martin

> I wouldn't do both backups at the same time personally, If
> something very wrong occurs to the system at backup time, I'd
> still have the secondary backup available for restore.
> 
> Things are a bit different when centralizing backup policies
> with tools like Amanda.
> 
> 
> > IMO the power savings from spinning down when not in active
> > use, do not compensate for the increased failure rate you'll
> > get under stop and start conditions.
> 
> Interesting opinion, it could be worth verifying.  Keeping a
> machine running for BOINC, I only had a disk issue once since
> the beginning of the decade.  Building disks has energy costs
> too indeed.
> 
> 
> Kind Regards,
> --
> Étienne Mollier 
> 
> 

Re: A Very Bad umount

[Gene Heskett]

On Wednesday 12 September 2018 13:12:43 Étienne Mollier wrote:

> Good Day Gene,
>
> Gene Heskett  2018-09-12T03:14 +0200 :
> > On Tuesday 11 September 2018 15:28:30 Martin McCormick wrote:
> >
> > [...]
> >
> > >Any constructive ideas are appreciated.  If I left
> > > the drives mounted all the time, there would be no spew but
> > > since these are backup drives, having them mounted all the
> > > time is quite risky.
> > >
> > > Martin McCormick WB5AGZ
> >
> > Why should you call that risky? I have been using amanda for
> > my backups with quite a menagerie of media since 1998. On 4
> > different boxes as I built newer, faster ones over the years.
>
> Should a badly placed “rm” command occur on the system, the
> system and both of its backup disks would be wiped clean.  I
> don't believe the risk mentioned here over was related to disk
> decay.  It was more about minimizing the time frame when this
> catastrophe could happen.
>
> I wouldn't do both backups at the same time personally, If
> something very wrong occurs to the system at backup time, I'd
> still have the secondary backup available for restore.
>
> Things are a bit different when centralizing backup policies
> with tools like Amanda.
>
> > IMO the power savings from spinning down when not in active
> > use, do not compensate for the increased failure rate you'll
> > get under stop and start conditions.
>
> Interesting opinion, it could be worth verifying.
> 
True, but actually has 2 identical systems, doing the same things to 
prove it.  So its difficult at best.

OTOH, someone like google that runs thousands of machines 24/7 is in the 
opposite camp, they have machines that are only down for disk 
replacements,  which they do in pallet qty's, at least for those 
machines facing the public. But just guessing, based on my own 
experience, I'd say they have records going back to the beginning of 
their search engine that would confirm to a high degree of certainty 
that letting them spin 24/7 till they do die is the most important point 
of their longevity. That drive I just pulled out at 77,000+ spinning 
hours had just under 50 powerdowns while it was in this machine since I 
built this one in 2007. My ups used to shut things off at about 7 or 8 
minutes, but its now been 3+ years since I had a 20kw generac with 
autostart and autotransfer put in, (the missus has end stage copd and a 
prolonged failure would probably finish her) so as far as this ups is 
concerned, there has only been one powerdown since as the powerfails 
have been in the 6 second territory, the startup and transfer delays. 
That leaves a hdwe failure, which there hasn't been except for bad sata 
cables, and its semi-annual shutdown and wheeled out to the front deck 
for a dusting and cleaning with an 80 lb air hose.

The rest of the 1T drives in this machine except for the 2T I just 
installed, have 40,000+ hours of spin time on them.

> Keeping a 
> machine running for BOINC, I only had a disk issue once since
> the beginning of the decade.  Building disks has energy costs
> too indeed.

True, but thats hidden in what you pay for them at the gitten place. ;-)

> Kind Regards,

Back to you, Étienne Mollier.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A Very Bad umount

[Étienne Mollier]

Good Day Gene,

Gene Heskett  2018-09-12T03:14 +0200 :
> On Tuesday 11 September 2018 15:28:30 Martin McCormick wrote:
>
> [...]
>
> >Any constructive ideas are appreciated.  If I left
> > the drives mounted all the time, there would be no spew but
> > since these are backup drives, having them mounted all the
> > time is quite risky.
> >
> > Martin McCormick WB5AGZ
>
> Why should you call that risky? I have been using amanda for
> my backups with quite a menagerie of media since 1998. On 4
> different boxes as I built newer, faster ones over the years.

Should a badly placed “rm” command occur on the system, the
system and both of its backup disks would be wiped clean.  I
don't believe the risk mentioned here over was related to disk
decay.  It was more about minimizing the time frame when this
catastrophe could happen.

I wouldn't do both backups at the same time personally, If
something very wrong occurs to the system at backup time, I'd
still have the secondary backup available for restore.

Things are a bit different when centralizing backup policies
with tools like Amanda.


> IMO the power savings from spinning down when not in active
> use, do not compensate for the increased failure rate you'll
> get under stop and start conditions.

Interesting opinion, it could be worth verifying.  Keeping a
machine running for BOINC, I only had a disk issue once since
the beginning of the decade.  Building disks has energy costs
too indeed.


Kind Regards,
-- 
Étienne Mollier 

Re: A Very Bad umount

[Gene Heskett]

On Tuesday 11 September 2018 15:28:30 Martin McCormick wrote:

[...]

>    Any constructive ideas are appreciated.  If I left the
> drives mounted all the time, there would be no spew but since
> these are backup drives, having them mounted all the time is
> quite risky.
>
> Martin McCormick WB5AGZ

Why should you call that risky? I have been using amanda for my backups 
with quite a menagerie of media since 1998. On 4 different boxes as I 
built newer, faster ones over the years.

Most recently like 2 weeks back, I retired the drive I had been using for 
virtual tapes for the last 77 thousand spinning hours in favor of a new 
one twice the size. It had 25 re-allocated sectors the first time I 
checked it, at about 3k spinning hours. It was still showing that same 
25 re-allocated sectors the day I pulled it out as it was not big 
enough, hovering at around 90% capacity for the last year.

Not once in all those mounted and spinning hours, has it had even a hint 
of a problem because its mounted 24/7/365 minus a few seconds for my 
backup generator to start, which averages around 4x a year.

I used to worry about it, but HD's that aren't ever unmounted and spun 
down suffer far less damage from parking the heads on a still moving 
platter when the cushioning air film collapses as they stop, and 
dragging on that same platter for at least a turn during the spin up.

IMO the power savings from spinning down when not in active use, do not 
compensate for the increased failure rate you'll get under stop and 
start conditions.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A Very Bad umount

[Martin McCormick]

=?UTF-8?Q?=c3=89tienne_Mollier?=  writes:
> 
> Good Day,
> 
> Not sure if that is the kind of answer you would wish to
> expect, but have you considered doing umounts sequentially?
> (optionally after synchronizing file systems)
> 
>     sync
> umount /var/cache/rsnapshot
> umount /rsnapshot2
> umount /rsnapshot1
> 
> Each call is blocking, so it will help perhaps...
> 
> Kind Regards,
> --
> Étienne Mollier 

Thank you.  I was thinking of trying that very thing next.

If things are quiet for a month or so, I'll think it worked.

Martin

Re: A Very Bad umount

[Étienne Mollier]

On 9/11/18 9:28 PM, Martin McCormick wrote:
> #Combine 2 256-GB drives in to 1 512 GB drive.
> 
> mount /rsnapshot1
> mount /rsnapshot2
> mhddfs /rsnapshot1,/rsnapshot2 /var/cache/rsnapshot -o mlimit=100M 
>
-8<8<
>   I have actually tried 
> 
> umount /rsnapshot2 /rsnapshot1 /var/cache/rsnapshot
> 
> as well as
> 
> umount /var/cache/rsnapshot /rsnapshot2 /rsnapshot1 .  I was
> thinking that the order might make a difference but have gotten
> as many good runs with either order.

Good Day,

Not sure if that is the kind of answer you would wish to
expect, but have you considered doing umounts sequentially?
(optionally after synchronizing file systems)

    sync
umount /var/cache/rsnapshot
umount /rsnapshot2
umount /rsnapshot1

Each call is blocking, so it will help perhaps...

Kind Regards,
-- 
Étienne Mollier 

A Very Bad umount

[Martin McCormick]

This has all the earmarks of a race condition because it is
totally intermittent.  It succeeds maybe 80% of the time.

I am using rsync to backup a Linux system to a pair of
thumb drives which both appear to be healthy.  The mounting
process goes as follows:

#Combine 2 256-GB drives in to 1 512 GB drive.

mount /rsnapshot1
mount /rsnapshot2
mhddfs /rsnapshot1,/rsnapshot2 /var/cache/rsnapshot -o mlimit=100M 

If one does

# df -h /var/cache/rsnapshot
Filesystem   Size  Used Avail Use% Mounted on
/rsnapshot1;/rsnapshot2  463G  173G  267G  40% /var/cache/rsnapshot

That all works as it should.  One can run rsnapshot and
get a backup of today's file system.

The /etc/rsnapshot.conf file is set to call the mount
process before rsync runs and then do the umount after it finishes

cmd_preexec /usr/local/etc/mtbkmedia

# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
cmd_postexec/usr/local/etc/umbkmedia

My problem may be with how I am unmounting everything so
umbkmedia follows:

#!/bin/sh
umount /var/cache/rsnapshot /rsnapshot2 /rsnapshot1 
exit 0

Normally, this simply works and /var/cache/rsnapshot ends up
empty but when one of these intermittent explosions happens, I
receive the following

Date:Tue, 11 Sep 2018 00:06:23 -0500
From:root@wb5agz (Cron Daemon)
Subject: Cron  /usr/local/etc/daily_backup

From root@wb5agz Tue Sep 11 00: 06:24 2018

/bin/rm: cannot remove '/var/cache/rsnapshot/halfday.1/wb5agz/home/usr/lib/i386
-linux-gnu': Transport endpoint is not connected
/bin/rm: cannot remove '/var/cache/rsnapshot/halfday.1/wb5agz/home/usr/lib/libg
pgme-pth.so.11': Transport endpoint is not connected

That is the beginning of what was, to day, a 152-line
message in which all of the error messages ended in
"Transport endpoint is not connected"

When I have discovered one of these crashes, I have
re-run the script as root and it usually runs perfectly the
second time defying the definition of madness which is to keep
doing the same and expect different results.  You frequently get
them in the form of a proper backup.

Today, I manually re-ran the backup and this time, it
actually failed from the command line with the same error
messages for each file mentioned.  The spew frequently highlights
a different set of directories.

Look at the two drives later and they are fine except
that one does not get the last backup as rsync saw the errors and
you're left with the last good backup.

I did a ls /var/cache/rsnapshot after the big spew and
got an error about "Transport endpoint is not connected" again.

I have actually tried 

umount /rsnapshot2 /rsnapshot1 /var/cache/rsnapshot

as well as

umount /var/cache/rsnapshot /rsnapshot2 /rsnapshot1 .  I was
thinking that the order might make a difference but have gotten
as many good runs with either order.

If one looks in /var/log/syslog, one sees the mounting of
the two drives and no errors and there are no errors reported if
you watch it happen.

Are there any ideas on how to do the umount to insure
that all the inodes are in the state they should be in before the
umount is done?
Normally, this blocks until every inode is set and the umount succeeds.

I have been chasing this rabbit for quite a while now and
it can sometimes be weeks without a spew, just long enough to
think that the last rejiggering of the order for unmounting or
someother futile rearranging of the Titanic's deck chairs actually
made a difference.

Any constructive ideas are appreciated.  If I left the
drives mounted all the time, there would be no spew but since
these are backup drives, having them mounted all the time is
quite risky.

Martin McCormick WB5AGZ

Re: umount /media/cleusb qu'en root

[Alain Rpnpif]

Bonjour,

Le 22 janvier 2016, andre_deb...@numericable.fr a écrit :

> On Friday 22 January 2016 19:29:58 andre_deb...@numericable.fr wrote:
> > On Friday 22 January 2016 18:58:30 Yann Justdohit wrote:
> > > Le 22 janvier 2016 14:50:03 UTC+1, andre_...@numericable.fr a écrit :
> > > > Sous Jessie, la clé USB s'ouvre automatiquement,
> > > > lorsqu'elle est introduite dans un port usb.
> > > > Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> > > > Par contre, je ne peux libérer/démonter la clé USB,
> > > > qu'en mode console, en tant que root, par la commande :
> > > > # umount /media/cleusb
> > > > Comment faire pour démonter la clé USB par son icône
> > > > établie sur le bureau, en tant que user ?
> 
> J'ai trouvé une solution qui semble fonctionner :
> /etc/fstab : "users" à la place de "user"
> /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0
> 
> André

Cette méthode n'est pas fiable car la clé peut changer de système
dev si on en monte plusieurs, comme par exemple /dev/sdd1, etc.

La clé USB est probablement gérée par udisks de Jessie ou-et les dérivés
de gvfs.

Pour la démonter sans les droits de root, il suffit de lancer 
udisksctl unmount -b /dev/sdX avec x le pilote de clé.
par exemple /dev/sdc1.
Ou bien :
udisksctl unmount -p block_devices/sdc1

Anciennement c'était la commande udisks du paquet udisks. Mais il
semble qu'avec le nouveau paquet udisks2, elle soit remplacée par
udisksctl pour éviter root.

Voilà.
-- 
Alain Rpnpif

Re: umount /media/cleusb qu'en root

[Sébastien NOBILI]

Bonjour,

Le vendredi 22 janvier 2016 à 23:06, andre_deb...@numericable.fr a écrit :
> J'ai trouvé une solution qui semble fonctionner :
> /etc/fstab : "users" à la place de "user"
> /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0

Ton problème est là. Pourquoi enregistrer de manière statique des directives de
montage pour un périphérique non-statique (clé USB en l'occurrence) ?

Retire cette ligne et ça fonctionnera mieux.

Sébastien

Re: umount /media/cleusb qu'en root

[Haricophile]

Le Sun, 24 Jan 2016 14:25:23 +0100,
Sébastien NOBILI  a écrit :

> Ton problème est là. Pourquoi enregistrer de manière statique des
> directives de montage pour un périphérique non-statique (clé USB en
> l'occurrence) ?
> 
> Retire cette ligne et ça fonctionnera mieux.

On peux utiliser l'uuid de la clé mais effectivement c'est une méthode
"ancienne manière". Il vaut mieux pour faire des montages avec des
paramètres spécifiques utiliser une méthode plus dynamique basée sur
udev.

Tout ça sent l'installation via une clé USB, et j'ai cru voir que les
images netinstall récentes avaient modifié ce comportement par
défaut.

-- 
haricoph...@aranha.fr 

Re: umount /media/cleusb qu'en root

[andre_debian]

On Sunday 24 January 2016 15:04:37 Alain Rpnpif wrote:
> Le 22 janvier 2016, andre_deb...@numericable.fr a écrit :
> > > > > Sous Jessie, la clé USB s'ouvre automatiquement,
> > > > > lorsqu'elle est introduite dans un port usb.
> > > > > Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> > > > > Par contre, je ne peux libérer/démonter la clé USB,
> > > > > qu'en mode console, en tant que root, par la commande :
> > > > > # umount /media/cleusb
> > > > > Comment faire pour démonter la clé USB par son icône
> > > > > établie sur le bureau, en tant que user ?
> > J'ai trouvé une solution qui semble fonctionner :
> > /etc/fstab : "users" à la place de "user"
> > /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0

On Sunday 24 January 2016 14:25:23 Sébastien NOBILI wrote:
> Le vendredi 22 janvier 2016 à 23:06, andre_deb...@numericable.fr a écrit :
> > J'ai trouvé une solution qui semble fonctionner :
> > /etc/fstab : "users" à la place de "user"
> > /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0
> 
> Ton problème est là. Pourquoi enregistrer de manière statique des directives
> de montage pour un périphérique non-statique (clé USB en l'occurrence) ?
> Retire cette ligne et ça fonctionnera mieux.
> Cette méthode n'est pas fiable car la clé peut changer de système
> dev si on en monte plusieurs, comme par exemple /dev/sdd1, etc.

Merci, je vais voir asap.

> La clé USB est probablement gérée par udisks de Jessie ou-et les dérivés
> de gvfs.
> Pour la démonter sans les droits de root, il suffit de lancer 
> udisksctl unmount -b /dev/sdX avec x le pilote de clé.
> par exemple /dev/sdc1.
> Ou bien :
> udisksctl unmount -p block_devices/sdc1
> Anciennement c'était la commande udisks du paquet udisks. Mais il
> semble qu'avec le nouveau paquet udisks2, elle soit remplacée par
> udisksctl pour éviter root.
> Voilà.

unmount ou umount ?
Commandes à lancer une fois ou à chaque fois ?
Si à chaque fois, quel intérêt ?
Le montage se fait automatiquement dès la clé introduite.
Le démontage se fait par une icône sur le bureau (clic droit).

André

Re: umount /media/cleusb qu'en root

[Alain Rpnpif]

Le 24 janvier 2016, andre_deb...@numericable.fr a écrit :


> unmount ou umount ?
> Commandes à lancer une fois ou à chaque fois ?
> Si à chaque fois, quel intérêt ?
> Le montage se fait automatiquement dès la clé introduite.
> Le démontage se fait par une icône sur le bureau (clic droit).
> 
> André

unmount, c'est une option d'udisks2 à ne pas confondre avec la commande
umount.

Je répondais à ta demande car tu semblais t'orienter vers la ligne de
commande ou bien j'ai mal lu. Si tu préfères le clic, Thunar de Xfce a
ce qu'il te faut ou (Nautilus pour Gnome, Dolphin de KDE, etc.).

En tout cas, c'est bien udisks2 et consorts qui gèrent tout ça en
tâche de fond ou pas. Des démons udisks2 sont d'ailleurs aussi actifs
chez moi sous Xfce.

ps ax | grep udisk
2498Sl 0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
2500Ssl0:00 /usr/lib/udisks2/udisksd --no-debug

-- 
Alain Rpnpif

Re: umount /media/cleusb qu'en root

[Bernard Schoenacker]

Le Sun, 24 Jan 2016 20:12:59 +0100,
andre_deb...@numericable.fr a écrit :

> On Sunday 24 January 2016 14:25:23 Sébastien NOBILI wrote:
> > Le vendredi 22 janvier 2016 à 23:06, andre_deb...@numericable.fr a
> > écrit :  
> > > J'ai trouvé une solution qui semble fonctionner :
> > > /etc/fstab : "users" à la place de "user"
> > > /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0  
> 
> > Ton problème est là. Pourquoi enregistrer de manière statique des 
> > directives de montage pour un périphérique non-statique 
> > (clé USB en l'occurrence) ? 
> > Retire cette ligne et ça fonctionnera mieux.
> > Sébastien  
> 
> C'est ce que j'ai fait et voici la réponse au démontage par l'icône :
> 
> "Malheureusement, le périphérique system:/media/sdc1 (/dev/sdc1) 
> nommé 29.8GB Removable Device et actuellement monté dans /media/usb0 
> n'a pas pu être libéré"
> 
> Pourtant j'ai supprimé avant /media/sdc1.
> 
> André
> 

bonjour,

dans le cas du montage automatique il existe :

/media/andré

https://www.youtube.com/watch?v=hkX386gD9yc

c'est "dédé-lirant"

http://lea-linux.org/documentations/Fiches:Comment_utiliser_ma_cl%C3%A9_usb_%3F

slt
bernard

Re: umount /media/cleusb qu'en root

[andre_debian]

On Sunday 24 January 2016 14:25:23 Sébastien NOBILI wrote:
> Le vendredi 22 janvier 2016 à 23:06, andre_deb...@numericable.fr a écrit :
> > J'ai trouvé une solution qui semble fonctionner :
> > /etc/fstab : "users" à la place de "user"
> > /dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0

> Ton problème est là. Pourquoi enregistrer de manière statique des 
> directives de montage pour un périphérique non-statique 
> (clé USB en l'occurrence) ? 
> Retire cette ligne et ça fonctionnera mieux.
> Sébastien

C'est ce que j'ai fait et voici la réponse au démontage par l'icône :

"Malheureusement, le périphérique system:/media/sdc1 (/dev/sdc1) 
nommé 29.8GB Removable Device et actuellement monté dans /media/usb0 
n'a pas pu être libéré"

Pourtant j'ai supprimé avant /media/sdc1.

André

Re: umount /media/cleusb qu'en root

[Alain Rpnpif]

Le 24 janvier 2016, andre_deb...@numericable.fr a écrit :
> 
> C'est ce que j'ai fait et voici la réponse au démontage par l'icône :
> 
> "Malheureusement, le périphérique system:/media/sdc1 (/dev/sdc1) 
> nommé 29.8GB Removable Device et actuellement monté dans /media/usb0 
> n'a pas pu être libéré"
> 
> Pourtant j'ai supprimé avant /media/sdc1.

Bizarre.
Bien sûr, il ne faut pas supprimer /media/sdc1 si le montage est en
cours.

Avec Jessie, maintenant les chemins de montage sont sous la
forme /media/nom_de_l_utilisateur/nom_de_la_clé.

Udev est bien installé ?

J'essaierais de redémarrer le système afin d'effacer les montages
fantômes-orphelins ce qui arrive quand une clé a été retiré
physiquement alors que le démontage n'est pas ou mal fait.

-- 
Alain Rpnpif

Re: umount /media/cleusb qu'en root

[andre_debian]

On Sunday 24 January 2016 20:38:36 Bernard Schoenacker wrote:
> dans le cas du montage automatique il existe :
> /media/andré
> https://www.youtube.com/watch?v=hkX386gD9yc
> c'est "dédé-lirant"
>http://lea-linux.org/documentations/Fiches:Comment_utiliser_ma_cl%C3%A9_usb_%3F
> slt bernard

Prière de se convertir dans un autre secteur,

Serait-il possible de le faire très vite !

Voir image jointe du secteur et métier qui correspondent parfaitement.

slt
andré

Re: umount /media/cleusb qu'en root

[Klaus Becker]

Le vendredi 22 janvier 2016, 19:29:58 andre_deb...@numericable.fr a écrit :
> On Friday 22 January 2016 18:58:30 Yann Justdohit wrote:
> > Le 22 janvier 2016 14:50:03 UTC+1, andre_...@numericable.fr a écrit :
> > > Sous Jessie, la clé USB s'ouvre automatiquement,
> > > lorsqu'elle est introduite dans un port usb.
> > > Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> > > Par contre, je ne peux libérer/démonter la clé USB,
> > > qu'en mode console, en tant que root, par la commande :
> > > # umount /media/cleusb
> > > Comment faire pour démonter la clé USB par son icône
> > > établie sur le bureau, en tant que user ?
> > 
> > Dans konqueror tape media:/ dans la barre d'adresse puis fait un
> > click-droit
> sur ta clef puis "demonter" ou "safely remove"
> 
> Je n'ai pas cette proposition "demonter" ou "safely remove",
> dans /media/ => cleusb sous Konqueror.
> 
> André

'soir,

dans dolphin, ça marche très bien

Klaus

Re: umount /media/cleusb qu'en root

[Yann Justdohit]

Le vendredi 22 janvier 2016 14:50:03 UTC+1, andre_...@numericable.fr a écrit :
> Bonjour,
> 
> Excuses si cette question a été posée...
> 
> Sous Jessie, la clé USB s'ouvre automatiquement,
> lorsqu'elle est introduite dans un port usb.
> Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> 
> Par contre, je ne peux libérer/démonter la clé USB,
> qu'en mode console, en tant que root, par la commande :
> # umount /media/cleusb
> 
> Comment faire pour démonter la clé USB par son icône
> établie sur le bureau, en tant que user ?
> 
> Merci.
> 
> André

Dans konqueror tape media:/ dans la barre d'adresse puis fait un click-droit 
sur ta clef puis "demonter" ou "safely remove"

@+

Re: umount /media/cleusb qu'en root

[andre_debian]

On Friday 22 January 2016 18:58:30 Yann Justdohit wrote:
> Le 22 janvier 2016 14:50:03 UTC+1, andre_...@numericable.fr a écrit :
> > Sous Jessie, la clé USB s'ouvre automatiquement,
> > lorsqu'elle est introduite dans un port usb.
> > Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> > Par contre, je ne peux libérer/démonter la clé USB,
> > qu'en mode console, en tant que root, par la commande :
> > # umount /media/cleusb
> > Comment faire pour démonter la clé USB par son icône
> > établie sur le bureau, en tant que user ?

> Dans konqueror tape media:/ dans la barre d'adresse puis fait un click-droit 
sur ta clef puis "demonter" ou "safely remove"

Je n'ai pas cette proposition "demonter" ou "safely remove",
dans /media/ => cleusb sous Konqueror.

André

Re: umount /media/cleusb qu'en root

[andre_debian]

On Friday 22 January 2016 19:29:58 andre_deb...@numericable.fr wrote:
> On Friday 22 January 2016 18:58:30 Yann Justdohit wrote:
> > Le 22 janvier 2016 14:50:03 UTC+1, andre_...@numericable.fr a écrit :
> > > Sous Jessie, la clé USB s'ouvre automatiquement,
> > > lorsqu'elle est introduite dans un port usb.
> > > Je peux y lire et écrire, supprimer des fichiers sous Konqueror.
> > > Par contre, je ne peux libérer/démonter la clé USB,
> > > qu'en mode console, en tant que root, par la commande :
> > > # umount /media/cleusb
> > > Comment faire pour démonter la clé USB par son icône
> > > établie sur le bureau, en tant que user ?

J'ai trouvé une solution qui semble fonctionner :
/etc/fstab : "users" à la place de "user"
/dev/sdc1  /media/sdc1  auto  users,noauto,rw 0   0

André

Re: usb device umount option in menu missing for some devices [SOLVED]

[deloptes]

For the record

in
/opt/trinity/share/apps/konqueror/servicemenus/media_unmount.desktop

add

media/camera_mounted

to

[Desktop Entry]
X-TDE-ServiceTypes=,media/camera_mounted

at the end of the list like above.

Then reload the desktop session and the unmount option appears as expected.

regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mj7vos$8q1$1...@ger.gmane.org

Re: usb device umount option in menu missing for some devices

[deloptes]

Liam O'Toole wrote:

 
 Are you using GNOME (the default) in Jessie? If so, the device should
 appear in the nautilus sidebar, with an 'unmount' icon next to it.
 

No I use trinity, but in my opinion it is not about the desktop but how the
device is associated with the set of options to display.
So it must be something in dbus. I think it gets recognized as a digicamera
as it says extract pictures in one of the options, but of course I don't
see this when I plug a usb stick - so it makes me think something is
missing in this set of options.
So where this gets set on system level?

thanks


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mj4mdn$uqu$1...@ger.gmane.org

Re: usb device umount option in menu missing for some devices

[Liam O'Toole]

On 2015-05-13, deloptes delop...@yahoo.com wrote:
 Hi
 where I can look for a resolution of following problem.

 When I plug usb stick or memory card in the notebook I see the option in the
 menu to mount/umount it and it works great.

 When I plug the phone (select use as usb storage device in the phone) it
 appears in the menu and I can mount it but consequently there is no option
 to umount it. How can this be corrected?

 /dev/sdb on /media/Nokia N9 type vfat
 (rw,nosuid,nodev,noatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-15,shortname=lower,showexec,utf8,errors=remount-ro,uhelper=udisks)

 I have to execute
 udisks --unmount /dev/sdb
 in the shell in this case - which is not nice enough

 thanks

Are you using GNOME (the default) in Jessie? If so, the device should
appear in the nautilus sidebar, with an 'unmount' icon next to it.

-- 

Liam



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnml9rre.1qm.liam.p.otoole@dipsy.tubbynet

usb device umount option in menu missing for some devices

[deloptes]

Hi
where I can look for a resolution of following problem.

When I plug usb stick or memory card in the notebook I see the option in the
menu to mount/umount it and it works great.

When I plug the phone (select use as usb storage device in the phone) it
appears in the menu and I can mount it but consequently there is no option
to umount it. How can this be corrected?

/dev/sdb on /media/Nokia N9 type vfat
(rw,nosuid,nodev,noatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-15,shortname=lower,showexec,utf8,errors=remount-ro,uhelper=udisks)

I have to execute
udisks --unmount /dev/sdb
in the shell in this case - which is not nice enough

thanks


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mj0fh6$ibk$4...@ger.gmane.org

sudo umount hangs when booting with systemd

[Zenaan Harkness]

I have a directory /media/USB01

Nothing is mounted on this directory.

When I run the following, after booting up with systemd, the command hangs:
sudo umount /media/USB01

A Ctrl-C breaks the hang.

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point   type  options   dump  pass
# / was on /dev/sda5 during installation
UUID=e73a71d3-a391-40bc-9d45-55fa72f245c1 / ext4
errors=remount-ro,nodiratime,noatime,user_xattr,journal_async_commit,min_batch_time=1000
0 1
# /boot was on /dev/sda3 during installation
UUID=75e1d222-c9df-4d10-93de-9da4cf005158 /boot ext2 defaults 0 2
# swap was on /dev/sda6 during installation
UUID=25d4ff20-1c78-4e1d-bd2a-2a0060e85f9a none  swap sw

# The following is done by /etc/default/rcS RAMTMP=yes option
#tmpfs /tmp tmpfs defaults,nodiratime,noatime,mode=1777

#/zenlocal/zen/justa /home/justa none bind,comment=systemd.automount
/zenlocal/zen/justa /home/justa none bind
/zenlocal/zen/  /home/justa/zen none bind

UUID=9E18AD0C18ACE50D /media/c ntfs-3g defaults,uid=1000,gid=1000,noauto

UUID=3EE6330B1FADCDD2 /media/SNAP01 ntfs-3g
defaults,uid=1000,gid=1000,posixovl,nodiratime,noatime,comment=systemd.automount
UUID=6fce0b79-b658-4072-af58-376a5630c190 /media/z55 ext3
user,nodiratime,noatime,comment=systemd.automount

/dev/sr0/media/cdrom0   udf,iso9660 user,noauto
/dev/sdb1   /media/usb0 auto
rw,user,noauto,nodiratime,noatime  0   0
/dev/sdb2   /media/usb1 auto
rw,user,noauto,nodiratime,noatime  0   0
/dev/sdb3   /media/usb2 auto
rw,user,noauto,nodiratime,noatime  0   0
/dev/sdb4   /media/usb3 auto
rw,user,noauto,nodiratime,noatime  0   0
/dev/sdb5   /media/usb4 auto
rw,user,noauto,nodiratime,noatime  0   0


Perhaps these two lines above are causing a problem for systemd's auto- stuff?:
/zenlocal/zen/justa /home/justa none bind
/zenlocal/zen/  /home/justa/zen none bind

Also, ls /media/ works, but ls -l /media/ similarly hangs! Again,
Ctrl-C aborts the hung command.

Any ideas?
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caosgnst4jij-bbmu+d3fo0wbt5_9hctfdgooyesjcuatfcp...@mail.gmail.com

Re: sudo umount hangs when booting with systemd

[Zenaan Harkness]

On 12/15/13, Zenaan Harkness z...@freedbms.net wrote:

 /etc/fstab :

 /zenlocal/zen/justa /home/justa none bind
 /zenlocal/zen/  /home/justa/zen none bind

Removing these solved the problem. I have unwound my two bind mount
mounts (with the sequence as above - not recursive, but the latter
bind mounted inside the former bind mount), and systemd no longer
borks in its hanging way. I now just use a single bind mount. I had
things set up the way I did, to assist in the days when I had multiple
debian and ubuntu installs, and would choose here and there between
them.

Another small issue that arose when I uncommented the first of the
above two lines, was that
ls -lF /
would hand, similarly to the mount hang. That problem's gone too now.

SOLVED

Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caosgnsqgriw4mroyeaht1eaonjqszuqomsuqtbac-smzhqt...@mail.gmail.com

Re: sudo umount hangs when booting with systemd

[Zenaan Harkness]

On 12/15/13, Zenaan Harkness z...@freedbms.net wrote:
 On 12/15/13, Zenaan Harkness z...@freedbms.net wrote:

 /etc/fstab :

 /zenlocal/zen/justa /home/justa none bind
 /zenlocal/zen/  /home/justa/zen none bind

 Removing these solved the problem.

 Another small issue that arose when I uncommented the first of the
 above two lines, was that
 ls -lF /
 would hand, similarly to the mount hang. That problem's gone too now.

would hang that should be.

Notably, ls -l / would not hang, only ls -lF / . So it was the -F or
--classify option to ls which stumbled upon systemd's mount internals,
it seems.

Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOsGNSTLS9TKJ=zfisbscebxxntpra1cm0gqtqvsshwg8wo...@mail.gmail.com

davfs2: umount no longer waits for cache synchronization

[Bill Brelsford]

Beginning with 1.4.7-1.1 (wheezy), unmounting a davfs filesystem
returns immediately:

  $ umount /foo/dav
  $
  
The waiting while mount.davfs (pid ) synchronizes the cache
message is not printed; cache synchronization continues in the
background.  It appears that umount.davfs is not being called.
Bug?  Or do I have something configured wrong?

-- 
Bill Brelsford
w...@k2di.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ungbr-0003sp-md@k2di.net

User unable to umount

[Erwan David]

Hi have following line in my /etc/fstab
//server/dir   /mnt/dir cifs   
defaults,user,noauto,sec=krb50   0

mounting works flawlessly, unsing the ticket obtained through pam_krb5 at login.

However

umount /mnt/it leads to :

umount: only root can unmount //server/dir from /mnt/dir

There is no point to allowing user to mount but forbiding them yo umount the 
directory they mounted.

DO someone have an idea on this problem, or should I report a bug against 
umount ?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530070505.gs13...@rail.eu.org

Re: User unable to umount

[Ralf Mardorf]

On Thu, 2013-05-30 at 09:05 +0200, Erwan David wrote:
   Hi have following line in my /etc/fstab
 //server/dir   /mnt/dir cifs   
 defaults,user,noauto,sec=krb50   0
 
 mounting works flawlessly, unsing the ticket obtained through pam_krb5 at 
 login.
 
 However
 
 umount /mnt/it leads to :
 
 umount: only root can unmount //server/dir from /mnt/dir
 
 There is no point to allowing user to mount but forbiding them yo umount the 
 directory they mounted.
 
 DO someone have an idea on this problem, or should I report a bug against 
 umount ?

You can use tools to mount and unmount as user, e.g. gvfs, something
that I've got removed from my Linux. What's edited in fstab isn't
mounted by the user. A regular mount and umount can only be done by
root.

I've written workarounds and never felt the need to write something
better, to e.g. mount CDs, since it's easy to become root or to use sudo
and than use regular Linux commands.

[rocketmouse@archlinux ~]$ cat /usr/local/sbin/lmount
#!/bin/sh

# /usr/local/sbin/lmount

case $1 in
  -r|-w) mkdir -p /mnt/$2
 if [ -e /media/$2 ] ; then :
 else
   ln -s /mnt/$2 /media/$2
 fi
 case $1 in
   -r) mount -rL$2 /mnt/$2;; 
   -w) mount -wL$2 /mnt/$2 -o noatime;;
 esac ;;
 -u) umount $(blkid -L$2)
 rm /media/$2; rmdir /mnt/$2;;
  --help|-h) echo
 echo Usage of /usr/local/sbin/lmount
 echo
 echo mount read-only
 echo   lmount -r label
 echo mount read/write noatime
 echo   lmount -w label
 echo unmount
 echo   lmount -u label
 echo ;;
esac
exit

[rocketmouse@archlinux ~]$ cat /usr/local/bin/tmount
#!/bin/sh

# /usr/local/bin/tmount

case $1 in
  --help|-h) echo
 echo Usage of /usr/local/bin/tmount
 echo
 echo mount read-only
 echo   tmount -r label
 echo mount read/write noatime
 echo   tmount -w label
 echo unmount
 echo   tmount -u label
 echo; exit;;
 -u) gksudo lmount $*;;
  *) gksudo lmount $*; thunar /mnt/$2; gksudo lmount -u $2;;
esac
exit

Regards,
Ralf


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1369903837.3138.75.camel@archlinux

Re: User unable to umount

[Erwan David]

On Thu, May 30, 2013 at 10:50:37AM CEST, Ralf Mardorf 
ralf.mard...@alice-dsl.net said:
 On Thu, 2013-05-30 at 09:05 +0200, Erwan David wrote:
  Hi have following line in my /etc/fstab
  //server/dir   /mnt/dir cifs   
  defaults,user,noauto,sec=krb50   0
  
  mounting works flawlessly, unsing the ticket obtained through pam_krb5 at 
  login.
  
  However
  
  umount /mnt/it leads to :
  
  umount: only root can unmount //server/dir from /mnt/dir
  
  There is no point to allowing user to mount but forbiding them yo umount 
  the directory they mounted.
  
  DO someone have an idea on this problem, or should I report a bug against 
  umount ?
 
 You can use tools to mount and unmount as user, e.g. gvfs, something
 that I've got removed from my Linux. What's edited in fstab isn't
 mounted by the user. A regular mount and umount can only be done by
 root.

That's what the user option in fstab is for. The fact here is to allow
cifs authentication using kerberos credentials, thus the mount must be
done by the user.

And it works well, except for unmounting...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530085904.ga4...@rail.eu.org

Re: User unable to umount

[Ralf Mardorf]

On Thu, 2013-05-30 at 10:59 +0200, Erwan David wrote:
 On Thu, May 30, 2013 at 10:50:37AM CEST, Ralf Mardorf 
 ralf.mard...@alice-dsl.net said:
  On Thu, 2013-05-30 at 09:05 +0200, Erwan David wrote:
 Hi have following line in my /etc/fstab
   //server/dir   /mnt/dir cifs   
   defaults,user,noauto,sec=krb50   0
   
   mounting works flawlessly, unsing the ticket obtained through pam_krb5 at 
   login.
   
   However
   
   umount /mnt/it leads to :
   
   umount: only root can unmount //server/dir from /mnt/dir
   
   There is no point to allowing user to mount but forbiding them yo umount 
   the directory they mounted.
   
   DO someone have an idea on this problem, or should I report a bug against 
   umount ?
  
  You can use tools to mount and unmount as user, e.g. gvfs, something
  that I've got removed from my Linux. What's edited in fstab isn't
  mounted by the user. A regular mount and umount can only be done by
  root.
 
 That's what the user option in fstab is for. The fact here is to allow
 cifs authentication using kerberos credentials, thus the mount must be
 done by the user.
 
 And it works well, except for unmounting...

I don't know this tool, but note, this tool seems to mount on a very low
system level, while gvfs is a tool used with GUI file browsers.

You shouldn't be allowed to simply unmount something on a low system
level, when you're running a multi-user OS.

I don't know what kind of security rules gvfs and what kind of rules
this thingy here does use, but I suspect it's not that easy just to
check, if a mounted dir is in use. Once it's mounted and a user has
permission, e.g. by a group, to mount and use mounted dirs, then it
could be, that a user planed to start a script in some minutes, that
does need the mounted dir, so it wouldn't be ok, if another user is
allowed to unmount this dir.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1369906233.3138.85.camel@archlinux

Re: User unable to umount

[Erwan David]

On Thu, May 30, 2013 at 11:30:33AM CEST, Ralf Mardorf 
ralf.mard...@alice-dsl.net said:
 On Thu, 2013-05-30 at 10:59 +0200, Erwan David wrote:
  On Thu, May 30, 2013 at 10:50:37AM CEST, Ralf Mardorf 
  ralf.mard...@alice-dsl.net said:
   On Thu, 2013-05-30 at 09:05 +0200, Erwan David wrote:
Hi have following line in my /etc/fstab
//server/dir   /mnt/dir cifs   
defaults,user,noauto,sec=krb50   0

mounting works flawlessly, unsing the ticket obtained through pam_krb5 
at login.

However

umount /mnt/it leads to :

umount: only root can unmount //server/dir from /mnt/dir

There is no point to allowing user to mount but forbiding them yo 
umount the directory they mounted.

DO someone have an idea on this problem, or should I report a bug 
against umount ?
   
   You can use tools to mount and unmount as user, e.g. gvfs, something
   that I've got removed from my Linux. What's edited in fstab isn't
   mounted by the user. A regular mount and umount can only be done by
   root.
  
  That's what the user option in fstab is for. The fact here is to allow
  cifs authentication using kerberos credentials, thus the mount must be
  done by the user.
  
  And it works well, except for unmounting...
 
 I don't know this tool, but note, this tool seems to mount on a very low
 system level, while gvfs is a tool used with GUI file browsers.
 
 You shouldn't be allowed to simply unmount something on a low system
 level, when you're running a multi-user OS.
 
 I don't know what kind of security rules gvfs and what kind of rules
 this thingy here does use, but I suspect it's not that easy just to
 check, if a mounted dir is in use. Once it's mounted and a user has
 permission, e.g. by a group, to mount and use mounted dirs, then it
 could be, that a user planed to start a script in some minutes, that
 does need the mounted dir, so it wouldn't be ok, if another user is
 allowed to unmount this dir.

That's a standard Unix tool, and I think it is a posix behaviour. The
settings must be in fstab with the specific user option.

I do not use gvs (nor any g*) because of dependdencies and I do not trust it.

As a grpahical tool I use smb4k, but it seems unable to do kerberos
authentication nor automatically mount a mount point at start of
session


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530095006.gb4...@rail.eu.org

Re: User unable to umount

[Klaus]

On 30/05/13 10:50, Erwan David wrote:

On Thu, May 30, 2013 at 11:30:33AM CEST, Ralf Mardorf 
ralf.mard...@alice-dsl.net said:

On Thu, 2013-05-30 at 10:59 +0200, Erwan David wrote:

On Thu, May 30, 2013 at 10:50:37AM CEST, Ralf Mardorf 
ralf.mard...@alice-dsl.net said:

On Thu, 2013-05-30 at 09:05 +0200, Erwan David wrote:

Hi have following line in my /etc/fstab
//server/dir   /mnt/dir cifs   
defaults,user,noauto,sec=krb50   0

mounting works flawlessly, unsing the ticket obtained through pam_krb5 at login.

However

umount /mnt/it leads to :

umount: only root can unmount //server/dir from /mnt/dir

There is no point to allowing user to mount but forbiding them yo umount the 
directory they mounted.

DO someone have an idea on this problem, or should I report a bug against 
umount ?


You can use tools to mount and unmount as user, e.g. gvfs, something
that I've got removed from my Linux. What's edited in fstab isn't
mounted by the user. A regular mount and umount can only be done by
root.


That's what the user option in fstab is for. The fact here is to allow
cifs authentication using kerberos credentials, thus the mount must be
done by the user.

And it works well, except for unmounting...


I don't know this tool, but note, this tool seems to mount on a very low
system level, while gvfs is a tool used with GUI file browsers.

You shouldn't be allowed to simply unmount something on a low system
level, when you're running a multi-user OS.

I don't know what kind of security rules gvfs and what kind of rules
this thingy here does use, but I suspect it's not that easy just to
check, if a mounted dir is in use. Once it's mounted and a user has
permission, e.g. by a group, to mount and use mounted dirs, then it
could be, that a user planed to start a script in some minutes, that
does need the mounted dir, so it wouldn't be ok, if another user is
allowed to unmount this dir.


That's a standard Unix tool, and I think it is a posix behaviour. The
settings must be in fstab with the specific user option.

I do not use gvs (nor any g*) because of dependdencies and I do not trust it.

As a grpahical tool I use smb4k, but it seems unable to do kerberos
authentication nor automatically mount a mount point at start of
session



Erwan,

although I don't have anything cifs set up, I do use the user option
in fstab. And with both, local disc partitions (ext4) or NFS
partitions, it works as you and I expect it to work: a user can mount
and unmount those partitions. Just guessing now, but could your issues
have something to do with the specifics of the cifs protocol?

--
Klaus


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/51a733d4.2050...@gmail.com

Re: User unable to umount

[recoverym4n]

On Thu, 30 May 2013 11:50:06 +0200
Erwan David er...@rail.eu.org wrote:

 I do not use gvs (nor any g*) because of dependdencies and I do not trust it.
 
 As a grpahical tool I use smb4k, but it seems unable to do kerberos
 authentication nor automatically mount a mount point at start of
 session

 Hi.

Looks like you've been hit by Debian bug #660431:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660431

Basically, umount.cifs and possibly other umount helpers are
deliberately broken upstream to comply with some obscure systemd design
oddity.

A workaround seems to be:

a) umount cifs filesystem
b) remove symlink /etc/mtab
c) create an empty file /etc/mtab
d) mount cifs filesystem


In my case I said 'screw this', and started using smbnetfs, which:

a) Definitely can be used without root and /etc/fstab entries.
b) Features automatic mounting and un-mounting cifs filesystems.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130531004425.c136ac82da106d8228445...@gmail.com

Re: trying to umount a chroot /dev

[T o n g]

On Wed, 22 Aug 2012 09:54:09 +0100, Roger Leigh wrote:

  Why did you choose rbind over bind.  Just curious.
 
 The advantage of using rbind is that you don't have to mount
 /dev/pts and /dev/shm (or just /dev/pts on wheezy since
 /dev/shm has been moved to /run/shm) after mounting /dev.
 
 This approach is really nice, and schroot used to do this.  There's just
 one niggle:
 
 If you use systemd, it will kill your system because autofs mounts under
 /dev created by systemd can't be bind mounted; well, they can, they are
 just broken and umountable, and all the processes in your system will
 slowly enter D state!

Interesting. What is systemd? (apt-cache search systemd shows me nothing) 

How can I tell if I'm using systemd or not?

I ask because till now, I always use rbind for /dev under chroot, because 
of the above advantage. 

-- 
Tong (remove underscore(s) to reply)
  http://xpt.sourceforge.net/techdocs/
  http://xpt.sourceforge.net/tools/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/k1hd03$nfv$3...@ger.gmane.org

Re: trying to umount a chroot /dev

[Bob Proulx]

T o n g wrote:
 Interesting. What is systemd? (apt-cache search systemd shows me nothing) 

'systemd' is an alternative 'sysvinit' system.

 How can I tell if I'm using systemd or not?

If you don't know then you are not using it.  You are using sysvinit
if you haven't manually taken action to change from it.

  dpkg -l sysvinit

Bob


signature.asc
Description: Digital signature

Re: trying to umount a chroot /dev

[Ross Boylan]

On Tue, 2012-08-21 at 23:20 -0600, Bob Proulx wrote:
 
 Try using the umount -l option for a lazy unmount.  Might work.  Might
 not work.  If it doesn't then I think you need to reboot.
Kind of works.
umount -l /mnt/chrtest/dev
no error messages. And it's no longer listed in /proc/mounts
Despite that,
umount /mnt/chrtest - device is busy
umount -l /mnt/chrtest - no complaints

But
# lvchange -an daisy/chrtest
  Can't change snapshot logical volume chrtest
# lvremove daisy/chrtest; date
  Can't remove open logical volume chrtest

Ross


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1345620410.9282.122.ca...@corn.betterworld.us

Re: trying to umount a chroot /dev

[Tom H]

On Tue, Aug 21, 2012 at 9:46 PM, Ross Boylan r...@biostat.ucsf.edu wrote:

 I setup a chroot on a snapshot.  Part of the setup was
 mount --rbind /dev /mnt/chrtest/dev

 I have exited the chroot and, I believe, ended the processes I started.
 umount /mnt/chrtest/dev
 gives umount: /mnt/chrtest/dev: device is busy

 How can I get this to work?

 After reviewing the output of mount I umounted the mounts below /dev,
 which seems to be the main advice on the net for undoing rbinds.

 The net also mentions using lsof to see what is accessing the file
 system.  lsof isn't much help because it shows everything that is
 touching /dev (I presume--it's a long list), and I can't shut all that
 down without a reboot.

 My ultimate goal is to destroy the snapshot, but neither lvremove nor
 lvchange -an work with the volume in use.

Since you used rbind, you must also have mounted
submounts/subdirectories of /dev like its and shm. Try
umount-ing /dev with -l or umount-ing all three.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOdo=sx+nr4neonxphzenvrz4pnfwpqpvtuelu2j+-wibll...@mail.gmail.com

Re: trying to umount a chroot /dev

[Roger Leigh]

On Tue, Aug 21, 2012 at 06:46:35PM -0700, Ross Boylan wrote:
 I setup a chroot on a snapshot.  Part of the setup was
 mount --rbind /dev /mnt/chrtest/dev
 
 I have exited the chroot and, I believe, ended the processes I started.
 umount /mnt/chrtest/dev
 gives umount: /mnt/chrtest/dev: device is busy
 
 How can I get this to work?

All the answers have been good ones.

I just wanted to mention that if you want to do this regularly,
the schroot program can automatically snapshot your chroot with
LVM and mount the /dev (and other) filesystems.  It then
subsequently umounts the filesystems and deletes the snapshot.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120822074027.ge22...@codelibre.net

Re: trying to umount a chroot /dev

[Tom H]

On Tue, Aug 21, 2012 at 10:21 PM, Bob Proulx b...@proulx.com wrote:
 Ross Boylan wrote:

 I setup a chroot on a snapshot.  Part of the setup was
 mount --rbind /dev /mnt/chrtest/dev

 Why did you choose rbind over bind.  Just curious.

The advantage of using rbind is that you don't have to mount
/dev/pts and /dev/shm (or just /dev/pts on wheezy since
/dev/shm has been moved to /run/shm) after mounting /dev.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOdo=SzbMpFoUpGF=9fexvmzabbp00dc9ovvfatbshycq7r...@mail.gmail.com

Re: trying to umount a chroot /dev

[Ross Boylan]

On Wed, 2012-08-22 at 08:40 +0100, Roger Leigh wrote:
 On Tue, Aug 21, 2012 at 06:46:35PM -0700, Ross Boylan wrote:
  I setup a chroot on a snapshot.  Part of the setup was
  mount --rbind /dev /mnt/chrtest/dev
  
  I have exited the chroot and, I believe, ended the processes I started.
  umount /mnt/chrtest/dev
  gives umount: /mnt/chrtest/dev: device is busy
  
  How can I get this to work?
 
 All the answers have been good ones.
 
 I just wanted to mention that if you want to do this regularly,
 the schroot program can automatically snapshot your chroot with
 LVM and mount the /dev (and other) filesystems.  It then
 subsequently umounts the filesystems and deletes the snapshot.
 
That sounds a lot like what I'm trying to do, including the snapshot.
Does schroot do any special tricks to umount dev?

Ross



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1345622422.9282.125.ca...@corn.betterworld.us

Re: trying to umount a chroot /dev

[Roger Leigh]

On Wed, Aug 22, 2012 at 01:00:22AM -0700, Ross Boylan wrote:
 On Wed, 2012-08-22 at 08:40 +0100, Roger Leigh wrote:
  On Tue, Aug 21, 2012 at 06:46:35PM -0700, Ross Boylan wrote:
   I setup a chroot on a snapshot.  Part of the setup was
   mount --rbind /dev /mnt/chrtest/dev
   
   I have exited the chroot and, I believe, ended the processes I started.
   umount /mnt/chrtest/dev
   gives umount: /mnt/chrtest/dev: device is busy
   
   How can I get this to work?
  
  All the answers have been good ones.
  
  I just wanted to mention that if you want to do this regularly,
  the schroot program can automatically snapshot your chroot with
  LVM and mount the /dev (and other) filesystems.  It then
  subsequently umounts the filesystems and deletes the snapshot.
  
 That sounds a lot like what I'm trying to do, including the snapshot.
 Does schroot do any special tricks to umount dev?

No.  It just recursively umounts every filesystem in the chroot,
depth-first.  For mounting, it just uses a regular fstab, so you
can mount whatever you like.  The only difference is that the
mountpoint has the chroot path prefixed to it, so you can mount
filesystems outside the chroot (like /home) inside it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120822084619.ga30...@codelibre.net

Re: trying to umount a chroot /dev

[Roger Leigh]

On Wed, Aug 22, 2012 at 03:41:50AM -0400, Tom H wrote:
 On Tue, Aug 21, 2012 at 10:21 PM, Bob Proulx b...@proulx.com wrote:
  Ross Boylan wrote:
 
  I setup a chroot on a snapshot.  Part of the setup was
  mount --rbind /dev /mnt/chrtest/dev
 
  Why did you choose rbind over bind.  Just curious.
 
 The advantage of using rbind is that you don't have to mount
 /dev/pts and /dev/shm (or just /dev/pts on wheezy since
 /dev/shm has been moved to /run/shm) after mounting /dev.

This approach is really nice, and schroot used to do this.  There's
just one niggle:

If you use systemd, it will kill your system because autofs mounts
under /dev created by systemd can't be bind mounted; well, they can,
they are just broken and umountable, and all the processes in your
system will slowly enter D state!


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120822085409.gb30...@codelibre.net

trying to umount a chroot /dev

[Ross Boylan]

I setup a chroot on a snapshot.  Part of the setup was
mount --rbind /dev /mnt/chrtest/dev

I have exited the chroot and, I believe, ended the processes I started.
umount /mnt/chrtest/dev
gives umount: /mnt/chrtest/dev: device is busy

How can I get this to work?

After reviewing the output of mount I umounted the mounts below /dev,
which seems to be the main advice on the net for undoing rbinds.

The net also mentions using lsof to see what is accessing the file
system.  lsof isn't much help because it shows everything that is
touching /dev (I presume--it's a long list), and I can't shut all that
down without a reboot.

My ultimate goal is to destroy the snapshot, but neither lvremove nor
lvchange -an work with the volume in use.

linux kernel 2.6.26-2-686.

Thanks.
Ross


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/134555.9282.91.ca...@corn.betterworld.us

Re: trying to umount a chroot /dev

[Bob Proulx]

Ross Boylan wrote:
 I setup a chroot on a snapshot.  Part of the setup was
 mount --rbind /dev /mnt/chrtest/dev

Why did you choose rbind over bind.  Just curious.  My reply is
the one I would give if you had used bind.  I have never used rbind.
The result may be wrong for rbind.  But it would be right for bind.

 I have exited the chroot and, I believe, ended the processes I started.
 umount /mnt/chrtest/dev
 gives umount: /mnt/chrtest/dev: device is busy
 
 How can I get this to work?

Unmount that path.  Look at /proc/mounts for the path to anything
mounted in that directory tree and unmount it.  You will see something
like this bind mount.

  udev /srv/chroot/sid/dev devtmpfs 
rw,relatime,size=10240k,nr_inodes=493001,mode=755 0 0

In which case the umount command would be:

  # umount /srv/chroot/sid/dev

 After reviewing the output of mount I umounted the mounts below /dev,
 which seems to be the main advice on the net for undoing rbinds.

I think instead of unmounting below /dev you needed to unmount below
/mnt/chartest/dev instead.

If you really get stuck then rebooting should restore things to a sane
state since those mounts will not exist after a reboot.  But you
should be able to recover without rebooting.

Bob


signature.asc
Description: Digital signature

Re: trying to umount a chroot /dev

[Ross Boylan]

On Tue, 2012-08-21 at 20:21 -0600, Bob Proulx wrote:
 Ross Boylan wrote:
  I setup a chroot on a snapshot.  Part of the setup was
  mount --rbind /dev /mnt/chrtest/dev
 
 Why did you choose rbind over bind.  Just curious.  My reply is
 the one I would give if you had used bind.  I have never used rbind.
 The result may be wrong for rbind.  But it would be right for bind.
I started with nothing mounted under /dev (and maybe /proc and /sys too)
in the chroot and kept adding things that I needed to make screen and
aptitude, and the package installers (e.g., some needed df to work)
happy inside the chroot.  At first I just mounted /dev/pts, but found
that was not enough.  rbind picks up /dev/pts and /dev/shm.

It's certainly not something to take as a model; it's just what sort of
worked for me.
 
  I have exited the chroot and, I believe, ended the processes I started.
  umount /mnt/chrtest/dev
  gives umount: /mnt/chrtest/dev: device is busy
  
  How can I get this to work?
 
 Unmount that path.  Look at /proc/mounts for the path to anything
 mounted in that directory tree and unmount it.  You will see something
 like this bind mount.
 
   udev /srv/chroot/sid/dev devtmpfs 
 rw,relatime,size=10240k,nr_inodes=493001,mode=755 0 0
my host system shows
udev /mnt/chrtest/dev tmpfs rw,size=10240k,mode=755 0 0
 
 In which case the umount command would be:
 
   # umount /srv/chroot/sid/dev
The corresponding command is the one I tried.  That failed with device
is busy.
 
  After reviewing the output of mount I umounted the mounts below /dev,
  which seems to be the main advice on the net for undoing rbinds.
 
 I think instead of unmounting below /dev you needed to unmount below
 /mnt/chartest/dev instead.
I was speaking loosely; I meant below /dev in the chroot,
i.e., /mnt/chrtest/dev/pts and the shm directory.  Those mounts are now
gone, as verified by /proc/mounts (/proc/mounts on the host system).

/dev/pts is still mounted on the host.
 
 If you really get stuck then rebooting should restore things to a sane
 state since those mounts will not exist after a reboot.  But you
 should be able to recover without rebooting.
That's my hope.

It might be relevant that I began with a logical volume mounted
at /mnt/chroot, with various submounts including /mnt/chroot/dev.  I
created a snapshot of the first logical volume and mounted it
at /mnt/chrtest.  I mounted stuff under it, ran some tests, shut down
what I could in the /mnt/chrtest chroot, and umounted what I could.  But
I can't seem to umount /mnt/chrtest/dev or (as a result, I
think) /mnt/chrtest itseelf.

Ross



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1345611934.9282.117.ca...@corn.betterworld.us

Re: trying to umount a chroot /dev

[Bob Proulx]

Ross Boylan wrote:
 Bob Proulx wrote:
  Why did you choose rbind over bind.  Just curious.
 
 It's certainly not something to take as a model; it's just what sort of
 worked for me.

Understood.  We are all pragmatic when need be.  :-)

# umount /srv/chroot/sid/dev
 The corresponding command is the one I tried.  That failed with device
 is busy.

Try using the umount -l option for a lazy unmount.  Might work.  Might
not work.  If it doesn't then I think you need to reboot.

Bob


signature.asc
Description: Digital signature