FSTAB CIFS mounts - lockout on lost connection and wait timer on reboot


I’m running a few entries in fstab to mount shares from my Windows 10 Pro, 64-bit “main system”. I’m only doing this because it seems to be the preferred method in regards to my requirements; fast browsing of large folders over LAN. This works good, with two annoying hiccups.

The problem: OSMC says something like “Path not found or invalid.” This occurs after the system that has the shared folders have had a reboot. Even though it’s back, and accessible on the network, OSMC looses the connection and does not try to remount. The only way out is to reboot or reload the daemon using systemctl daemon-reload followed by systemctl restart remote-fs.target (works sometimes). So usually a simple reboot is in order. Here’s the second hiccup. Because of some failsafe, OSMC won’t reboot until the mounts have been successfully unmounted. But because OSMC doesn’t recognize them anymore, all I can do is wait for the timeout. It’s usually 1min and 30 seconds, sometimes much longer.

I understand, sort of, why this happens. And it’s partly because of how things load up during boot, and the order it shuts down before a reboot or shutdown. As I understand it, it can’t unmount something it can’t find. So it keeps trying until a timeout happens. I believe it does this to prevent data loss. To “fix” this, I’ve googled and tried just about anything I can think of - to no avail.

So basically the question is, can I change the order of things somehow, or do something so that OSMC can respect the network.target requirement and simply just reboot? So that since the mounted shares are no longer reachable for OSMC, unmounting them shouldn’t be a problem. And I’m not worried about “data loss” in this case. So this feature is actually just an annoyance for me.

I’ve been fiddeling with the entries in fstab and their arguments to mount my shares with. Typically, a mounted share of mine looks like this:

//W10Pro64-PC/Movies /mnt/Movies/ cifs noauto,x-systemd.requires=network.target,x-systemd.automount,vers=3.0,sec=ntlmssp,credentials=/home/osmc/.smbcred,uid=1000,gid=1000,iocharset=utf8

That’s what is working best for me at the moment. It’s not as fast as I’d like it to be, but it’s far better than the Kodi built-in SMB approach. A few gotchas about some of the arguments I’m using:

  • CIFS, as I can’t get NFS to work any better
  • Hostname instead of IP as I’ve set it up from the router locked to the systems MAC addr.
  • requires network.target are attempts at fixing the “problem”
  • vers3 because v1 and v2 won’t work for me for some reason
  • sec=ntlmssp if I recall correctly was to get cifs working
  • uid and guid, tried osmc and 1000 but left it as 1000
  • charset utf8 I belive I set because latin chars or smth

I’ve just had to reboot my Vero 4K because for some unknown reason, even though main system hasn’t rebooted or lost connection I got “path not found or invalid…” message. Randomly loosing the mounted shares is new since 2 updates or so ago. Usually it happens if main system has had a reboot. Anyhow, as usual I tried to reboot where I have to wait an average of 3 minutes before it actually does.

The lost connection happens around 3 times a week. My Vero 4K is always on, so is my main system. So it’s enough to be irritating and annoying for me. I grabbed a log as soon as the system was back after finally rebooting:


Hopefully someone knows how to “fix” this behavior, even if it’s technically a feature.


Check this out


Regarding the use of network.target in your fstab file:

  • network.target is not going to be of much use to you, since its meaning is too loosely defined. See https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
  • OSMC has a more useful service called connman-wait-for-network.service that would be a better choice.
  • systemd knows that CIFS is a network protocol and acts accordingly, so the x-systemd.requires=network.target shouldn’t be necessary. As it stands, it should also have been accompanied by the option x-systemd.after=network.target.

FYI, you can also try restarting the automount job with sudo systemctl restart mnt-Movies.automount. You can also unmount a “stuck” mount (due to a missing source) with sudo systemctl stop mnt-Movies.automount. These assume a mount point of /mnt/Movies, as in your example.


Is there a way to get the automount to restart by itself? If my wifi connection doesn’t come up, by the time I’ve fixed it in MyOSMC, the automount has failed and needs a terminal connection to restart.


Try adding bg,x-systemd.mount-timout=0to the fstab line and see if that helps.