Automatically remount CIFS shares after they've been offline?

  • I have a setup where I share media from a Windows PC to a RPi 3b running LibreELEC 8.2.5 using CIFS mounts. I'm using the method outlined on the Wiki page (mount files in /storage/.config/system.d/). The problem I'm experiencing is that after the Windows PC has been asleep and woken, mounts are unavailable on the Pi (even though they're online) and the only method I know of to get them back is rebooting the Pi. Is there anything that can be added to the *.mount files to automatically remount the shares when they become available again/accessed? Or maybe a simple script that can be triggered remotely.

    I realize this setup isn't optimal and I'm planning to get a NAS but if there's a way to make this work in the meantime it would be great.

    EDIT1: Using plink I made a batch file that sends systemctl restart storage-*mountname*.mount for every mount point. While this works, it's a bit of an ugly workaround. Saves me from having to restart the Pi though.

    EDIT2: Adding noauto to Options= in the .mount files seems to have done ... something. Now instead of saying that the file is no longer available in Kodi it hangs when host is not online and seems to play the file normally when host is online again (resumed from sleep in this case). I though noauto only meant share isn't automatically mounted on boot but instead when first accessed. Is this option in fact the on-demand mounting that I'm looking for?

    Edited 3 times, last by osen (April 29, 2019 at 12:57 AM).

  • You could always create a unit that unmounts the shares before suspend (use WantedBy=sleep.target).

    I find udevil helpful for easy mounting of shares btw. "udevil --mount smb://server/share" creates a properly named directory under /media and mounts it for you.

  • You could write a python script, started from autostart.sh, which automatically mounts / re-mounts your CIFS.

    My knowledge of Python is minimal to non-existent I'm afraid. I'm more or less illiterate when it comes to coding in general. My batch file works as a temporary (idiot) workaround. Also adding noauto to the cifs mount options seems to be able to handle host going offline and coming back, but I'm not 100% sure yet. Also looking into using AutoFS, as it seems people claim it can handle this sort of situation better.

  • You could always create a unit that unmounts the shares before suspend (use WantedBy=sleep.target).

    I'm sorry, I don't understand what that means. Is this similar to the systemd mount files? Would this automatically unmount the shares when host goes offline and remount when it comes online again? Could you point me to an example file or similar?

    Quote

    I find udevil helpful for easy mounting of shares btw. "udevil --mount smb://server/share" creates a properly named directory under /media and mounts it for you.

    Interesting, I'll look into it. Would you recommend udevil over AutoFS (which is another alternative I've seen mentioned)?

  • osen

    They work a bit differently, udevil is more like a mount helper. It's used in LibreELEC by udev when block devices are connected. You can point it to a block device, an iso file or a network share and it will create mount point and do the mounting for you.

    AutoFS on the other hand runs as a daemon and mounts on demand. It mounts an underlying filesystem on the mount point that detects what you're trying to access, then mounts it and unmounts after a set timeout. Very useful for network mounts that can be problematic if they become unavailable for whatever reason. When properly set up, it makes NFS/CIFS mounts feel like they are local.

    There's only one problem, AutoFS isn't part of LE. Not sure they would want it either as Kodi handles network mounts through libraries and it works fairly well. There's a bit of good news though, as I like having AutoFS available I've packaged it up in my fork. Perhaps you or someone else who takes an interest in it would look at making it an addon (shouldn't be much trouble) and upstreaming it. It compiles and runs great both on arm and x86.