"a stop job is running" for samba unmount

Ok thanks for clarification!

Last question, I promise…
Now that this is in place when I shutdown or reboot, it hangs with this line:
a stop job is running for /mnt/SambaUsb (1min30)

Is there a way around this?

EDIT: ok so basically since I am on a share via WLAN , the network is shut down before it can unmount. So I don’t see a real solution. However, is there a way to reduce the time value (1min30)? That way it would be less of an annoyance…

EDIT 2 : I’ve tried to add _netdev but it seems it is not working either :frowning:

So, I’ve set up a samba share and added it to my fstab. I’m not seeing an issue with the 90sec hang when I reboot.

As x.automount?

Of course…

// /mnt/storage cifs credentials=/home/osmc/.smbcredentials,noauto,x-systemd.automount 0 0

Though this was on Vero2… Let me see if I can try on Rpi…

Will do some testing tomorrow. Are you on wired or wireless?

Ok, moved it to a new topic as I don’t think it is related to your original question and might have others impacted.
@ActionA, @DBMandrake, @sam_nazarko

Maybe you can do some testing on your side but for what I found I can confirm that when on wireless network and having a samba mount when you shutdown/reboot you get “a stop job is running” for the samba unmount.
This only happens when on wireless when I use wired on the same machine it shutsdown cleanly.
My fstab is
//osmc.my.hk/128G_video /mnt/osmc.my.hk cifs x-systemd.automount,noauto,iocharset=utf8,user,credentials=/home/osmc/.osmc.my.hk.smb,uid=osmc,gid=osmc,iocharset=utf8,file_mode=0770,dir_mode=0770 0 0

Yep, my machines are all wired.

The problem appears also only on a wireless connection in my case.
my fstab is : // /mnt/SambaUsb cifs noauto,x-systemd.automount,username=osmc,password=osmc 0 0


Which machine?

I’d like to clarify the issue. Are you saying that OSMC connected via Ethernet does not exhibit the problem, only when it’s connected via WiFi?

Hi Sam,

It’s a Pi2. And yes I confirmed if I use wired instead of wireless with the same machine the problem doesn’t appear.


Same as fzinken here on a Pi3.

But which is the server and which is the client?

pi3 is the client. So the share is always up. The problem comes from the WLAN connection and unmounting in the shutdown sequence I’d say imho.

Pi2 (OSMC) is the client and I have two shares mounted 1 is from Pi3 (OSMC) and one is from Gentoo Server.

Browsing the forum I’ve found other issues about this.
Here is one on NFS: Shutdown takes 1min 30s after mounting nfs in etc/fstab - #3 by EmilFrom

It always seems to be a WiFi only problem… (unmounting a network share on reboot seems to hang for 1min30 , NFS or Samba. )

Okay. I’ll see if I can replicate this soon.

Ok thank you ! To check that this is also the case with NFS I’ve set it up (fstab entry = /mnt/Nusb nfs noauto,x-systemd.automount,soft,tcp 0 0). I also get a stop job is running error at reboot for that particular mount.

I’ve been thinking… Could I somewhere add a line that makes the network share unmount when I click on rebooting (before actual shutdown takes place) ? Sorry if the question is dumb…

Then you’d have effectively solved the problem. As far as I’m aware, this is the crux of the problem.
When we have a solution, we’ll fix it in OSMC.

Well I’ve found a workaround, for my dual boot anyways. I have just added :
os.system(sudo umount /mnt/Nusb) , before the reboot line of the launcher I used for recalbox (thanks MattHuisman for the launcher) .
It works.
Obviously I still have the problem when I simply reboot OSMC.

A long shot idea might be to add an OSMC GUI setting to add network shares (which would add it to fstab, on a predefined pathname) . This way this could automatically add an umount “predefinedpathame” before the shutdown sequence. At the same time, it would make OSMC more userfriendly when it comes to network share (since os mounting is way faster than kodi access).