System-hang when browsing unconnected network share

[ghost]

What happens

I have Nemo bookmarks for shares on my local network. Those shares are controller, on the Linux side (they point to a Windows computer) by systemd and Samba and my fstab. Relevant part of the latter:

# Desktop
//192.168.1.51/Desktop	/mnt/Windows_Desktop	cifs	credentials=/home/nicholas/.smbcredentials,uid=1000,gid=1000,iocharset=utf8,rw,x-systemd.automount,noauto	0 0

# My Documents
//192.168.1.51/My\040Documents	/mnt/Windows_Docs	cifs	credentials=/home/nicholas/.smbcredentials,uid=1000,gid=1000,iocharset=utf8,rw,x-systemd.automount,noauto	0 0

# Y drive
//192.168.1.51/y	/mnt/Windows_Y	cifs	credentials=/home/nicholas/.smbcredentials,uid=1000,gid=1000,iocharset=utf8,rw,x-systemd.automount,noauto	0 0

# E drive
//192.168.1.51/Backup	/mnt/Windows_E	cifs	credentials=/home/nicholas/.smbcredentials,uid=1000,gid=1000,iocharset=utf8,rw,x-systemd.automount,noauto	0 0

When I am away from home, naturally I cannot connect to the local network. Yet, if I try to - via a Nemo bookmark - the whole system hangs. I have to press the reset button on the laptop computer.

What should happen

I should get an error mesage and the system should not hang. I hope the problem is with my particular setup. Otherwise, this is a serious bug - though, even if the problem is with my setup, surely it should be easier to create network shares (or at least ones that, unlike normal Samba shares, do not temporarily freeze the system when they are unavailable - though note that such a temporary freeze would be better than the hard-reset-necessitating situation that I am experiencing).

My system
Mint 18.1 x64. Nemo 3.2.2.

[Nackloose]

Can confirm I have the same issue, as well as same system. Although using SSHFS.
I've setup a custom shortcut in the keyboard settings menu, to force a cinnamon restart using Super+Shift+R and binding it to cinnamon --replace which seems to be fixing the issue on hanging without needing a full restart.

[Inphiltration]

I too have had this same issue using SSHFS. I have shoddy internet so i'd often lose my connection nemo would completely freeze if I tried to navigate back to my network share after a connection loss.

I've since moved to using filezilla but I would love to see a fix to this issue.

Mint 18 64-bit cinnamon version 3.0.7 nemo 3.0.6

[ghost]

I still have this problem (I was the one who reported it originally), even when using systemd mounts in fstab and even when those mounts - as specified in fstab - have timeout values. I have the problem not only with shares on another computer on my network (another computer attached to the same router) but also with a flash drive connected to the router.

It seems to me that this is a serious problem. Here's why. (Please correct my logic if it is incorrect.)

1. This problem involves a Nemo hang (such that there is a 'Nemo is not responding' message). (Premise.)
2. A Nemo hang is a serious problem, at least if it happens when people try to use something that is reasonably construed as basic functionality. (Premise.)
3. Trying to connect with network shares is reasonable construed as basic functionality. (Premise.)
4. This is a serious problem. (Inference, from the conjunction of 1, 2 and 3.)

I infer further - from 4 - that this should be fixed, and pronto (!).

[leigh123linux]

@ACinnamonUserInUK

Can you prove it's a nemo bug (it could equally be a gvfs-smb issue!!), you haven't provided any logs to help debug this issue.

that this should be fixed, and pronto (!)

That attitude isn't going to get the issue fixed any quicker, in fact you probably got it pushed to the bottom of the list!

[leigh123linux]

@DarthShekels
@Nackloose

Can you provide some error logs for the issue as all my sftp remote shares are working fine

[ghost]

@leigh123linux:

Thank you for the speedy response.

'Can you provide some error logs for the issue': please advise. I am familiar with Cinnamon's log viewer, and the KDE log viewer (which I use on Cinnamon), but I do not find either of those particularly easy to use and perhaps you would like me to look at something other than what is exposed to/by them.

(As to attitude: perhaps I shouldn't complain, but I don't think you should threaten to send-to-the-back, either.)

[leigh123linux]

@ACinnamonUserInUK

To capture gvfs, try

pkill gvfs; GVFS_DEBUG=all GVFS_SMB_DEBUG=10 /usr/lib/gvfs/gvfsd &> ~/log.txt

You might need to alter the gvfsd path to suit

[ghost]

@leigh123linux

I opened a Nemo window, browser to a Windows share - a share on a computer that was turned off - and ran the commands you gave me. Nemo froze for some 15 seconds but did, this time, produce an error message (rather than the system producing a 'not responding message). However, the error messsage window contained an 'OK' button that was unclickable - Nemo was not responding to input, even once the message was displayed. Also, before I issued sudo killall nemo, the file browser portion of my text editor - Sublime - hung as well. (Might that be because of the pkill gvfs?)

And after all this . . log.txt was zero byes, I am afraid.

EDIT [I had to submit the comment before I was finished, because the text box stopped responding]: There was relevant stuff in 'syslog', viz., multiple instances of the following.

Jan 28 00:06:50 Ns-laptop systemd[1]: mnt-Windows_Desktop.automount: Got automount request for /mnt/Windows_Desktop, triggered by 2649 (gmain)
Jan 28 00:06:50 Ns-laptop systemd[1]: Mounting /mnt/Windows_Desktop...
Jan 28 00:06:56 Ns-laptop mount[9219]: Unable to find suitable address.
Jan 28 00:06:56 Ns-laptop kernel: [  477.312383] CIFS VFS: Error connecting to socket. Aborting operation.
Jan 28 00:06:56 Ns-laptop kernel: [  477.312554] CIFS VFS: cifs_mount failed w/return code = -113
Jan 28 00:06:56 Ns-laptop systemd[1]: mnt-Windows_Desktop.mount: Mount process exited, code=exited status=32
Jan 28 00:06:56 Ns-laptop systemd[1]: Failed to mount /mnt/Windows_Desktop.
Jan 28 00:06:56 Ns-laptop systemd[1]: mnt-Windows_Desktop.mount: Unit entered failed state.

[Nackloose]

@leigh123linux I pasted what you typed and followed your methods, as well as tried logging the output to the console, but cant seem to get it to print anything at all ever. Not quite sure why.
I can properly replicate the freeze by starting an sshfs on the microserver next to me, and then after opening a folder in it, ie(Browsing to /var inside my mount point)
Then unplugging the cord from the server with nemo open.
Once the server is unplugged browse to /var/www and nemo (or at least its window) will hang.
(Upon additional testing, I dont seem to be able to open any new nemo windows whilst said window has been hung, but other already open windows appear to be working, and the desktop appears to be working in that I can copy to and from working windows, but cant open folders)
I am using a plain old sshfs command as follows for mounting:
sshfs /media/nackloose/Server/ [redacted server info]:/
I should also note that pkilling sshfs, and manually disconnecting my network adapter seems to boot me back to my home folder.
Double checked the location of gvfs to make sure it was correct, and it is, just to be safe as noted in your comment.

[leigh123linux]

@Nackloose Try running 'killall nemo' first before

pkill gvfs; GVFS_DEBUG=all GVFS_SMB_DEBUG=10 /usr/lib/gvfs/gvfsd &> ~/log.txt

alter the /usr/lib/gvfs/gvfsd to suit the true path location

[ghost]

I would like to add that I still have a less severe version of the problem. The decrease in severity could owe to software updates or to changes in my fstab but the situation is still not great. What happens now when the network drives are offline is as follows.

1. Nemo does not respond for a bit.
2. Then a window appears saying that the folder cannot be accessed.
3. Then, sometimes (not always) Nemo hangs and has to be force-quit (taking my desktop along with, until I restart Nemo).

1 is perhaps fine, given my fstab settings (see below), though some sort of indication that an access attempt is in progress would be good.
2 is fine.
3 is not fine.

My fstab setup:

# Desktop
//[IP - redacted]	/mnt/Windows_Desktop	cifs	credentials=[redacted],uid=1000,gid=1000,iocharset=utf8,rw,noauto,nofail,file_mode=0666,dir_mode=0777,x-systemd.automount,x-systemd.mount-timeout=5,x-systemd.device-timeout=10,x-systemd.idle-timeout=120min	0	0

[ghost]

To quote, and correct, myself:

I would like to add that I still have a less severe version of the problem

Actually, it transpires that I still have the original problem. That is: the computer hangs on logon if the network is offline (although, oddly, this seems to happen only on one of my two user accounts).

Here, belatedly (and @Nackloose), is another attempt at obtaining the output requested. First I tried it when my network was up.

~ $ sudo killall nemo
~ $ pkill gvfs; GVFS_DEBUG=all GVFS_SMB_DEBUG=10 /usr/lib/gvfs/gvfsd &> ~/log.txt

gvfsd:

Added new job source 0x717090 (GVfsBackendTrash)
Queued new job 0x717820 (GVfsJobMount)
send_reply(0x717820), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:CreateFileMonitor
Queued new job 0x717b80 (GVfsJobCreateMonitor)
send_reply(0x717b80), failed=0 ()
Added new job source 0xc3d090 (GVfsBackendComputer)
Queued new job 0xc3d850 (GVfsJobMount)
send_reply(0xc3d850), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x7022d0 (GVfsJobQueryInfo)
send_reply(0x7022d0), failed=0 ()

I will post this and then take the network offline and, if the computer still works (I won't turn it off in the meantime, so hopefully it will: logging on without the network is the problem), then I'll reissue the command and post the output.

[ghost]

The log after the network is taken down:

Failed to acquire daemon name, perhaps the VFS daemon is already running?

[ghost]

And the log when the network is down and after sudo killall nemo: well, my text editor hung (as it has done before, sometimes, when there is no network). But the tip posted above (by @Nackloose - thank you!) allowed me to recover - and log.txt had this:

Added new job source 0x11bd8a0 (GVfsBackendComputer)
Queued new job 0x11be030 (GVfsJobMount)
send_reply(0x11be030), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x11a8230 (GVfsJobQueryInfo)
send_reply(0x11a8230), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x11a82d0 (GVfsJobQueryInfo)
send_reply(0x11a82d0), failed=0 ()

[ghost]

The problem seems still present; compare also these other reports: #1627 #624 #781

[ghost]

Please note also that, since Nemo does not change the point to a 'busy' shape when it (Nemo) is trying to access a network share, it is hard to know whether or not Nemo has hung. (Cf. also these further bug reports: #424; #1412 (on which progress has been made, reportedly); #377.

[ghost]

A recent update to Samba seems to have made delays in shutting down - which already I have to tame with a watchdog and by modifying systemd timeouts - more frequent. It would be nice if something could be done about this by Mint.

[NoXPhasma]

This is still an issue!

[martin3000]

same here. If my NAS is down, nemo hangs for 35s

strace gives a lot of these lines:

access("/mnt/diskstation/music", F_OK) = -1 EINVAL (Invalid argument)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=11, events=POLLIN}], 3, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=4, revents=POLLIN}])
read(3, "\2\0\0\0\0\0\0\0", 16) = 8
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\0\1\0\f\0'\0\0\0\1\0\0\0\1\0\f\0(\0\0\0&\0\0\0\0\0\10\0"..., iov_len=1732}, {iov_base="", iov_len=2364}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 468
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x558e8cfa29e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x558e8cfb26e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f362ab4db80, FUTEX_WAKE_PRIVATE, 1) = 0
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7f361800ca50, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f361800c9e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x558e8cfbc088, FUTEX_WAKE_PRIVATE, 1) = 1

[CommonOddity]

Can confirm. This is definitely an issue. I have two servers on the same network, both acting as fileshares, amongst other things, via cifs. Both servers have respective mount points in /media, ergo, local to the filesystem rather than something like gvfs in /usr or a different directory altogether.

If either side becomes unreachable/unresponsive for whatever reason (e.g. Say that a server hangs for some reason)- nemo becomes insanely unresponsive. Even when I attempt to browse local directories that should be reachable and fine, it chugs along, hangs for long periods of time, then goes back to working for a few seconds.

It's as if it's struggling to attempt and access the previously mounted cifs/smb share in-between my requests to reach other local directories that are not remote.

[mikhailnov]

A fix of an issue with similar sympthoms in KDE: KDE/plasma-workspace@e1c19ce

[amithiel]

Hi!
I'm on LinuxMint 20 - Cinnamon, and this still happens. I have mounted my NAS folders (which is only on my local network).
If i lose internet, or i connect to another network outside my home, Nemo gets unstable because it can no longer mount the network drives. Anyone got some tips?

Edit: using NFS to mount

[mikhailnov]

Did anyone try mounting using GVFS? Does this happen with GVFS-mounted shares?

[amithiel]

Fixed by adding a few options to my mount:
nfs vers=3,nofail,rw,users 0 0

[NoXPhasma]

Fixed by adding a few options to my mount:
nfs vers=3,nofail,rw,users 0 0

This has no positive effect for me, Nemo still freezes as long as a copy/write operation to the remote drive is running.

[amithiel]

i'm sorry, i didn't explain myself properly. I was not transfering any data from/to the NAS. My nemo was freezing just by opening it, because of bookmarks in the sidebar which pointing to the NAS disks.
I never tried to disconnect the internet while transfering data.
cheers all

[CommonOddity]

Does that fix only apply to mounts/shares that rely on fstab entries? I have a systemd automount script that I'm using for my remote CIFS share. Not sure if this would translate...

Wouldn't it be better to fix the type of behavior that occurs when the file manager is opened? Why does it effectively 'hang' and spin its wheels when a share is unreachable? Perhaps I'm just dense and not getting something but shouldn't there be an 'nth attempt and backoff/stop' when accessing a share that is unreachable?

Everything literally just kind of 'stops'... However I am able to access things just fine from terminal while a remote share is inaccessible. It is literally just Nemo that this happens with.

[Perkolator]

If either side becomes unreachable/unresponsive for whatever reason (e.g. Say that a server hangs for some reason)- nemo becomes insanely unresponsive. Even when I attempt to browse local directories that should be reachable and fine, it chugs along, hangs for long periods of time, then goes back to working for a few seconds.

It's as if it's struggling to attempt and access the previously mounted cifs/smb share in-between my requests to reach other local directories that are not remote.

Same here. Just started using linux (Mint 20 Cinnamon) and this is really a drag for a laptop that sometimes is home and in the home network, and sometimes somewhere else completely. Also the laptop is rarely rebooted (when forced by system), only sleep and hibernate used. SMB3 shares mounted from fstab with cifs. Tried to use the nofail in fstab but it doesn't fix the problem. (I'm a linux noobie so forgive me if my writings are total gibberish.)

Long hang also happens almost every time (it's random, can't make out what causes this and not) e.g. when trying to save something from a web browser when the shares are not available; Vivaldi -> "Save as" -> there's a long hang before the "save file" dialog even shows up.

I have added bookmarks to the SMB shares in nemo. Shares are mounted under "$HOME/.smb/" folder in their own subfolders.

No processes gets seemingly stuck, and no high cpu usage, when looking at System Monitor or top when the hangs occur.

I got a "The folder contents could not be displayed. Sorry could not display all the contents of ".smb". Error when getting information for file "/home/(redacted)/.smb/Backup": Host is down" error dialog after a small hang when trying to navigate to the $HOME/.smb folder with nemo. Can't even see the ".smb" folder, nemo always goes back to the "$HOME" and shows the error dialog even though the shares are mounted in their own folders under the ".smb" folder.

Many times even when browsing to a non-share folder, e.g. "$HOME/downloads", there's a "loading..." indicator in the right-bottom corner of nemo. Nemo rarely totally hangs on my system, but things are slowed down and there's longer and shorter hangs with virtually everything user tries to do (though these also happen randomly), e.g. opening a txt file from non-share folder hangs for a while.

"journalctl" and "dmesg" pretty much show only this line (once only for some reason even though the hangs continue if navigating again and again to the shares that are not connected anymore):

kernel: CIFS VFS: \\\(ip_redacted) has not responded in 180 seconds. Reconnecting...

That's all I can report with my limited knowledge about linux.

---

A fix of an issue with similar sympthoms in KDE: KDE/plasma-workspace@e1c19ce

Could this be used as a reference to conjure a solution for nemo?

[Perkolator]

Can't even see the ".smb" folder, nemo always goes back to the "$HOME" and shows the error dialog even though the shares are mounted in their own folders under the ".smb" folder.

From terminal, ls hangs a bit before showing (the hang time multiplies with each share, so the more shares, the longer the hangs):

foo@bar:~/.smb$ ls -l
ls: cannot access 'Backup': Host is down
total 4
d????????? ? ?   ?    ?               ?  Backup
-rwxr-xr-x 1 foo foo 14 loka    6 21:38 'mount all fstab.sh'

Removing a bookmark for the share from nemo (after a hang when right-clicking the bookmark) helps a bit sometimes, for example, opening text documents are fast again, and also opening the "save as" dialog from e.g. Vivaldi browser. Still, this is not a fix for this problem.

Tried quitting nemo with nemo -q from the terminal but that didn't help. Switching to another user and back doesn't help.

---

For a temporary fix, I created a script that force unmounts all my smb shares and put it in my home folder for easy access:

#!/bin/bash
sudo umount -v -f ~/.smb/Backup
sudo umount -v -f ~/.smb/AnotherShareFolder
sudo umount -v -f ~/.smb/AndSoOn

echo

read -s -n 1 -p "Press any key to exit ..."

This can be ran when nemo starts hanging. If you run it from nemo itself, choose "Run in terminal" so that you can enter pw for sudo (the -f force option requires sudo). After force unmounting the shares, everything should be back to normal.

After force unmounting, clicking any of the SMB share bookmarks in nemo show this error message instantly with no hangs (how it should happen when the not available shares are still mounted):

Could not display "/home/foo/.smb/Backup".
Error: Error when getting information for file "/home/foo/.smb/Backup":
Host is down
Please select another viewer and try again.

[ghost]

Jesus christ nearly 6 years later and this still isn't fixed? I can't use my computer if a network share goes offline. I can't believe this isn't fixed. Good job devs.

[martin3000]

Jesus christ nearly 6 years later and this still isn't fixed? I can't use my computer if a network share goes offline. I can't believe this isn't fixed. Good job devs.

Switch from nemo to nautilus.

[leigh123linux]

Jesus christ nearly 6 years later and this still isn't fixed? I can't use my computer if a network share goes offline. I can't believe this isn't fixed. Good job devs.

It isn't wise to add networks shares to fstab, if you do add the nofail option so the PC can still boot when the share goes MIA.

#1378 (comment)

[Perkolator]

It isn't wise to add networks shares to fstab

Why? What is the better way then? Years ago I tried to mount/access the shares directly from Nemo (gvfsd?) and I couldn't get full gigabit speeds from my home network, the speed was reduced like over 60% or even more (I can't recall the exact amount, but it was a VERY large drop). Then tried to mount from fstab and I got full gigabit speed.

if you do add the nofail option so the PC can still boot when the share goes MIA.

This doesn't help people with laptops that use sleep &/ hibernate. Not everybody reboots daily. (at the time of writing this my uptime is 13 days.. and can be easily much longer)

Is this impossible to fix? Has anybody even tried to think of a fix for this? What about the link to a "fix of an issue with similar symptoms in KDE" which was posted here earlier, would that help fixing this? If I'd knew how to even start fixing this problem, I'd try to do it, but alas, I can't.

[martin3000]

I do "gio mount smb://diskstation/home" and it hangs also when the NAS ist not running.

[stephan-dev]

I have a good workaround, if anyone still has this problem in 2023.
I found it about a year ago, so my memory isn't clear, but I think I gathered that samba and/or udisks had tightened security at some point, and the key, when you know what you're doing, is to mount with forceuid.

sudo mount -v -t cifs -o username=myusername,uid=1000,gid=users,forceuid,forcegid,vers=1.0 //(samba share name) /(mount point that I choose)

I don't (maybe obviously?) use this in fstab, I never tried, I don't need it. The point being that all problems are gone since. It's weird how I never found this issue here, and the many duplicates. I remember heavy web searching back then.

Today I've had the problem again because, by mistake, I mounted a samba share through nemo (which I think uses udisks / gio mount / its own CIFS arguments). I'm not afraid of doing it since I learnt that nemo -q or DISPLAY=:0 nemo -q was the fix when laptop won't suspend. But this doesn't work when the router is off. After several searches I ended up here. Still curious about finding the most elegant workaround. For now, no luck, so I'll avoid nemo mounts more strictly. (but an ugly workaround for me is to switch the router back on, which serves the .local addresses that I need (fixes key.dns_resolver : my_hostname.local: No address associated with name)) (so maybe not 100% related to this issue, but all symptoms seem to be the same (Nemo freeze, slow terminal for unrelated things...))

Also now I remember it took me a long time to get rid of ALL problems, as Linux Mint relies heavily on gvfs, so for some time, some problems were fixed, but others weren't (for example, when saving a file from Firefox (gtk3 ?)). But one fine day I found the best list of arguments for me / for my mount cifs command (above) and all problems were gone.

[Perkolator]

I found it about a year ago, so my memory isn't clear, but I think I gathered that samba and/or udisks had tightened security at some point, and the key, when you know what you're doing, is to mount with forceuid.

Are you sure this is a working workaround?

I checked how my cifs were mounted with cat /proc/mounts | grep cifs, and these are part of every mount:
uid=1000,forceuid,gid=1000,forcegid. My fstab mounts do not have forceuid and forcegid but it seems that the system is using them automatically. And I have a problem with the freezing.

I think that the problem is twofold:

1. Nemo bookmarks to shares that are not available but still mounted, which causes very long freezes in various situations. EDIT2: It seems that more bookmarks to shares you have, the longer the freezes are.
2. When navigating to not available but still mounted shares in Nemo. Causes a long delay before showing an error message.

---

EDIT: Just for reference, here's a mount from my fstab file and output of /proc/mounts for that same mount:

//192.168.0.100/backups /home/myusername/.smb/backups cifs credentials=/home/myusername/.smb/.smbcredentials,iocharset=utf8,uid=myusername,gid=myusername,file_mode=0755,dir_mode=0755,nofail 0 0

//192.168.0.100/backups /home/myusername/.smb/backups cifs rw,relatime,vers=3.1.1,cache=strict,username=smbusername,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.0.100,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1 0 0

[martin3000]

for example, when saving a file from Firefox

When I download files with chromium and save them on my NAS, it seems to work but the files are not on the NAS. So I always download to my SDD and then move the files to the NAS.

[Perkolator]

When I download files with chromium and save them on my NAS, it seems to work but the files are not on the NAS. So I always download to my SDD and then move the files to the NAS.

I think you have some other problem (maybe related to GVFS that Nemo uses when mounting, IF you mount that way). I don't see how this is relevant to this issue/topic. I have no problem downloading/saving files from Vivaldi (Chrome/Chromium) straight to my NAS shares. Never had a problem with it, it has always worked fine, I do that daily, so I definitely would have noticed. Also the user you quoted, had that problem at some point but not anymore.

[stephan-dev]

@Perkolator

these are part of every mount: uid=1000,forceuid,gid=1000,forcegid. My fstab mounts do not have forceuid and forcegid but it seems that the system is using them automatically.

I didn't know that, I thought forceuid was the main trick. Interesting.
Have you tried, additionnally, mount -t cifs -o (...) gid=users,vers=1.0 ? Maybe you really need CIFS v3?

My comment was already long, but I wanted to add that at first I thought I had to have both my custom mounts and the gvfs mounts. My main goals were to have my network pictures in digiKam network collections, and to be able to query all my drives through one instance of mlocate (and not have Nemo freezes and problems at suspend). Each time I thought I had a fix and felt ready to share, one week later I was realizing there were still problems (esp. permissions problems). But after more "tweaks" of the mount.cifs options (shared in previous comment), all problems have been gone for a year (as long as I never use the nemo mounts (1)). I still have nemo samba mounts bookmarks, they don't cause problems when I don't click them. But I'm on Mint 19.3, not sure if that matters.

(1) One interesting case if with Timeshift. Btw it's not even related to Samba, but to the suspend bugs. I do my snapshots on an encrypted external disk. If I forget to mount it, Timeshift automatically creates a root mount, with udisks, of a nonexisting drive (because my LUKS container is closed). That mount appears in Nemo, and in the UI it looks a bit like a Samba Mount. Unmounting this is a bit tricky (because root, can't GUI), and if I forget to do it, the laptop can't suspend.

That (second paragraph above) is why I thought my list of mount.cifs option could be the fix for everyone, as I haven't had a problem in a year. I'm interested if you or others try gid=users,vers=1.0 (which is apparently the only difference you have with my full list of options sudo mount -v -t cifs -o username=myusername,uid=1000,gid=users,forceuid,forcegid,vers=1.0
(also, if that matters, I mount to /mnt)

=======================

edit : my /run/user/1000/gvfs/ is now empty (which is good). My samba mounts don't appear in gio mount -l I read that the point of Gio mounts is to make user mounts only in userspace (for security and flexibility), with FUSE. What we see in /run/user/1000/gvfs/ is just legacy. I really don't understand this clearly, but I know that samba always has to be on a tmpfs (temporary fs), and /run/ is one place where those tmpfs can be represented. At some point I thought that because of gtk applications, I needed to have both my custom CIFS mounts, and gio CIFS mounts. For example, I couldn't save a picture with Firefox to a samba mount. It looked like it worked, but then xviewer couldn't open them xviewer - Invalid parameter(s) - /run/user/1000/gvfs/smb-share:..../pic.jpg. Then I think I worked on permissions, and realized that Firefox actually worked better with neither gio mounts nor /run/gvfs/ mount points. Gio mounts are made automatically (udisks2... and maybe systemd automount ? / systemd generate...?). I guess that finally I found the mount.cifs options (above) that prevent udisks / gio from doing these gvfs mounts. And now everything works well. Maybe it's the combination of forceuid, forcegid gid=users... Or maybe they are not mounted automatically by systemd, maybe at some point I realized that I did not need the gvfs mounts, and should not do them. I just did a web search now, "how to prevent systemd from mounting samba shares with gio / udisks / gvfs", it didn't help, maybe the question doesn't make sense.

Basically my suggestion boils down to this : Try to do a manual CIFS mount that integrates well with gtk apps, while never using gio / udisks / gvfs mounts. That should avoid nemo problems. Before suspending the computer, make sure in Nemo that systemd (or a program like Timeshift) didn't auto mount any samba share / any network drive at all (or just unmount them each time).

[Perkolator]

I'm a bit swamped with everything, but I'll try to answer a bit.

I'm interested if you or others try gid=users,vers=1.0

Why "users"?

I'm not really interested in using a very old, insecure, and IF my memory serves me right, slower version of cifs/smb. I don't use version in my fstab mount because Mint automatically forces the newest (3.1.1) version (from journalctl):

No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.

BTW. I'm using Linux Mint Cinnamon 20.3.

Basically my suggestion boils down to this : Try to do a manual CIFS mount that integrates well with gtk apps, while never using gio / udisks / gvfs mounts.

I'm not a linux expert so bear with me; is mounting with fstab ok regarding what you wrote above?

[ghost]

8 years later and this still isn't fixed? Cinnamon freezes if SMB mount goes offline.

[henr7381]

I have a samba NAS mounted through FSTAB and opening Nemo when I'm not connected to my network causes Nemo to take an unreasonable amount of time to open.

[Perkolator]

Unfortunately it seems that no one that would have the knowledge to try to fix this is interested. :(

[martin3000]

You can use nautilus.