You are not logged in.
I'm running a small home server (SUSE) with an smb share drive. Works perfect for the whole family. It is our movie/music share.
I carry my developer laptop back and forth from work with this line in my fstab to access my home share:
//10.1.1.90/share /mnt/homeshare cifs _netdev,guest,nofail,noatime,uid=1000,gid=1000,iocharset=utf8,noperm 0 0
When I get to work and wake my laptop I can't get KDE/Plasma to let go of the share. It freezes when I open Dolphin or use a browse file dialog box. Of course, if I reboot all is well, but I'm not sure what I'm doing wrong.
Could someone point out my mistake?
Thanks!
Offline
Please use [code][/code] tags. Edit your post in this regard.
https://man.archlinux.org/man/extra/cif … .8.en#soft but that's supposed to be the default.
It freezes when I open Dolphin or use a browse file dialog box.
Is it actually the cifs share or the smb:// kio? Is "ls /mnt/homeshare" also affected?
My generic mitigational advice for any intermittent remote FS would be sth. like "noauto,x-systemd.automount,x-systemd.device-timeout=10,x-systemd.idle-timeout=5min" to only mount it on access and disconnect it after 5m of not using it, also because https://wiki.archlinux.org/title/Fstab#External_devices
Edit: then there's oc https://wiki.archlinux.org/title/Networ … SMB_shares and you could likewise leverage https://wiki.archlinux.org/title/Power_ … leep_hooks
Last edited by seth (2024-09-24 14:11:51)
Online
The problem is while your laptop is "sleeping" it still maintains a reference to the "currently mounted" cifs share. Attempts to access that from the other network will break things, but from the perspective of the operating system, the share is mounted so it "must be there". And from the perspective of an user space application, the fact that the mount point is a network share is transparent, which is why they don't have special handling for it
IMO most of the kernel level handling of cifs will have a bunch of drawbacks to it suddenly disappearing (you could e.g. unmount it on suspend and then check it's availability, or properly configure a systemd.automount that unmounts it when not actively used after a few minutes but properly handles access attempts transparently).
In a similar case (CIFS share for an university mount only available on campus/VPN) I handled it with a NetworkManager-dispatcher script that would unmount it on sleep and remount it when connection was established again (... on the correct network/VPN) but afaik that still had a few cases of similar issues.
I ultimately opted to not keep it in fstab, but setup user space mounts via the networking kio integration in dolphin itself. That way all systems interacting with this are aware of the network nature of the share and will handle it appropriately (drawback at the time - should not be the case anymore with kio-fuse - that the share only worked with KDE native applications)
But as you note I'm writing past tense, I haven't interacted with said share in a while.
Offline
Seth and V1del,
Thanks to you both for replying and sharing your suggestions. I think I should have also posted I was expecting shared drives to operate like Windows. You can plug and unplug from different networks and Windows didn't seem to care if the share was no longer available. Please note I am not criticizing Linux at all. I've had my fill of Windows and will never go back since switching to Linux.
I think I should have thought it through a bit more since I was adding it to fstab. I think moving it from fstab to a user mount will make it easier over all. I can easy add an icon to add or remove it at will.
Again, thank you both for the help and suggestions as I really do appreciate your time! Seth, I apologize for forgetting the tags as it slipped me mind.
Have a great week!
Offline
I was expecting shared drives to operate like Windows
Have you actually mounted a smb share on windows (yes, windows/ntfs actually can mount filesystems, go figure )?
Otherwise windows is more akin to the smb:// protocols provided by kio and gvfs - or smbclient.
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Online