is it defined in your fstab?Dwedit wrote: Mon Nov 18, 2019 7:42 pm I mentioned it in another thread.
It was the mount.cifs command.
su
cd /mnt
mkdir share
mount.cifs //192.168.2.51/share share
cifs mounts halt/delay shutdown on live system
- dolphin_oracle
- Developer
- Posts: 22686
- Joined: Sun Dec 16, 2007 12:17 pm
Re: cifs mounts halt/delay shutdown on live system
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
Live system help document: https://mxlinux.org/wiki/help-antix-live-usb-system/
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
Live system help document: https://mxlinux.org/wiki/help-antix-live-usb-system/
Re: cifs mounts halt/delay shutdown on live system
Not defined in fstab.
Re: cifs mounts halt/delay shutdown on live system
I just thought of another degenerate case.
Mount a CIFS filesystem
Mount a disk image inside of that filesystem
You cannot unmount the CIFS file system until the disk image is unmounted first.
Mount a CIFS filesystem
Mount a disk image inside of that filesystem
You cannot unmount the CIFS file system until the disk image is unmounted first.
Re: cifs mounts halt/delay shutdown on live system
Funny you guys are talking about this, as I just spent some time trying to work around this issue with a cifs share mounted in fstab. If it is still mounted when the system shuts down or restarts it will hang the system for a few minutes. If Thunar mounts the share as a network folder you are fine, but using the mount command causes the issue. Definitely looks like the wifi is being shut down before the cifs shares are unmounted. I was able to prevent the hang by changing the unmount command in my bash script to "umount -a -t cifs -l". Not a secure way to do things because I had to run sudo in the script, but a workaround nonetheless. I'm glad you guys are working on it.
Re: cifs mounts halt/delay shutdown on live system
Figuring out the dependencies of filesystems to unmount them cleanly will always be a problem, regardless of which type you decide to unmount first, it could be a dependency of another filesystem.
You could theoretically have this monstrosity:
- Loopback file system mounted on:
- Union file system mounted including:
- FUSE file system mounted on:
- Loopback file system mounted on:
- CIFS file system
So that would mean:
Network share has a disk image file on it
You mount that disk image
You run a FUSE file system using data from that mounted disk image
You mount a UNION file system that uses that FUSE filesystem
You mount a disk image on that UNION file system
And Linux would allow that. And if you're shutting down, going by mount type wouldn't be enough to unmount them in order. Trying to unmount all network filesystems first won't work, trying to unmount all the loopback filesystems first won't work, and trying to unmount all the FUSE filesystems won't work either.
It ends up becoming a graph problem to cleanly unmount filesystems in the correct order.
You could theoretically have this monstrosity:
- Loopback file system mounted on:
- Union file system mounted including:
- FUSE file system mounted on:
- Loopback file system mounted on:
- CIFS file system
So that would mean:
Network share has a disk image file on it
You mount that disk image
You run a FUSE file system using data from that mounted disk image
You mount a UNION file system that uses that FUSE filesystem
You mount a disk image on that UNION file system
And Linux would allow that. And if you're shutting down, going by mount type wouldn't be enough to unmount them in order. Trying to unmount all network filesystems first won't work, trying to unmount all the loopback filesystems first won't work, and trying to unmount all the FUSE filesystems won't work either.
It ends up becoming a graph problem to cleanly unmount filesystems in the correct order.