Join Log in
Score:1
grssnbchr avatar Ubuntu

Mounting an unreachable CIFS results in slow login and other problems

ru flag
grssnbchr

I have a NAS that I mount via CIFS. My /etc/fstab:

//192.168.178.1/FRITZ.NAS/ /home/xxx/NAS cifs credentials=/home\
/xxx/.smbcredentials,vers=3.0,noserverino,uid=1000,\
gid=1000,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10ms 0 0

I works well in my home network, of course, but as soon as I leave the house and 192... isn't available anymore, I experience very slow logins and other problems, i.e. when trying to browse my files with Nautilus or any other program that tries to access the file system.

dmesg then shows:

[ 1176.653340] CIFS: Attempting to mount //192.168.178.1/FRITZ.NAS/
[ 1186.984727] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 1186.984739] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1186.993225] CIFS: Attempting to mount //192.168.178.1/FRITZ.NAS/
[ 1197.224579] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 1197.224590] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1197.233060] CIFS: Attempting to mount //192.168.178.1/FRITZ.NAS/
[ 1207.464505] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 1207.464516] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1207.476803] CIFS: Attempting to mount //192.168.178.1/FRITZ.NAS/
[ 1217.705176] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 1217.705187] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1217.713857] CIFS: Attempting to mount //192.168.178.1/FRITZ.NAS/

So over the course of dozens of seconds, it tries to mount the NAS again and again, which seems to block the system entirely...

The timeout option I added doesn't seem to help, dmesg tells me it is ignored:

[ 1078.414184] systemd-fstab-generator[532]: x-systemd.device-timeout ignored for //192.168.178.1/FRITZ.NAS/

Also adding a nofail option doesn't help.

Isn't there an option to have a very short timeout so it doesn't bother me when I'm not in my home network?

285
1 + 3
vanadium avatar
cn flag
vanadium
Try the _netdev option.
0
Reply
codlord avatar
ru flag
codlord
My mistake, `fg/bg` are options on nfs mounts, so I have deleted comment.
0
Reply
grssnbchr avatar
ru flag
grssnbchr
@vanadium the _netdev option only helps if I'm not logged into another Wifi, i.e. if I'm completely off the grid, it doesn't block login anymore, but with wifi (even though it's not my home wifi), I have the same problems as before.
0
Reply
Score:1
Morbius1 avatar Ubuntu
es flag
Morbius1

This really depends on how you use this remote share but I think you have two options:

[1] Keep the systemd.automount but add another option and change your mount point.

You need to add noauto to your options and add it before x-systemd.automount.

You will also need to change your mount point to someplace other than in your home directory or under /media. Having it under these locations induces a udisks response that makes the automounter think it's being accessed.

Without these changes your system will always attempt to mount it automatically at boot.

[2] There is another way to do this that doesn't use the systemd automounter and you can keep your mount point:

Replace x-systemd.automount with noauto,user

A mount icon will appear on the side panel of your file manager that is actionable. Click on it and it will go to fstab to find out how and mount it with those instructions

Either method will mean the remote share will mount only when accessed and not automatically.

0 + 6
grssnbchr avatar
ru flag
grssnbchr
Thanks for your answer. The problem is that I still like to have automount when I'm at home. I'm running a backup tool (Duplicati) that needs access to the NAS, and if I always have to mount it manually, that's a bit tedious. Isn't there an option where automount will still work, and if it doesn't, it doesn't block stuff?
0
Reply
Morbius1 avatar
es flag
Morbius1
In option [1] you aren't mounting it manually. It is being mounted automatically when the mount point is accessed. That can happen if you access the mount point through your file manager, or is you do an `ls /mountpoint`in a terminal, or if a script or other service accesses that mount point. It is seamless to the user or process.
0
Reply
grssnbchr avatar
ru flag
grssnbchr
Okay. I tried option [2] for now. Turns out that when I click on the network device in Nautilus, a little spinning icon appears and then the NAS is mounted. However, when I access it otherwise (via the file manager by going to the mount point, via the CLI etc.), it's not mounted, so that's what [1] would be good for. But I can imagine that I could use some sort of a setup script before my backup script runs that mounts the volume with the `mount home/xxx/NAS` command, which seems to work without root privileges. So [2] is the option to go for me. Thanks!
0
Reply
grssnbchr avatar
ru flag
grssnbchr
I tested option [2] for a while. Unfortunately, I still have the unresponsive system problems and it tries to automount, so it doesn't really work. Here again is the content of my /etc/fstab: `//192.168.178.1/FRITZ.NAS/ /home/xxx/NAS cifs credentials=/home/xxx/.smbcredentials,vers=1.0,noserverino,uid=1000,gid=1000,noauto,user,x-systemd.requires=network-online.target 0 0`
0
Reply
Morbius1 avatar
es flag
Morbius1
I know of no process that would automount the share with noauto in the fstab record unless you have some script that runs at boot by default. If that is the case you should use another systemd option: `x-systemd.mount-timeout=5` "5" is for 5 seconds - use whatever you want. NOTE: This is different from the systemd "device-timeout" operand.
0
Reply
grssnbchr avatar
ru flag
grssnbchr
Okay, I will try this. In the meantime, option [1] works as intended and suits my usecase as well. Thanks!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.