Vero 4K loses connection to mount

I have my files mounted via fstab with cifs. Before the April/May update (I may have skipped April update) everything worked great.

Now, whenever I sit down to watch a show, it just spins, and eventually freezes. A reboot fixes things. I am not sure how long it takes sitting idle before this happens.

I have not made any changes to my network environment or the PC hosting these files.

Here are the logs. I turned on debug logging, rebooted, played a file successfully. I then left it for approx 4 hours. Then trying to play a file did not work, and it froze up. Hopefully the reboot after it was frozen didn’t clear logs.
(https://paste.osmc.tv/aqobuyubes)

Is the PC powered off/on, or goes to sleep sometimes? If so that could be the problem and autofs may be a better solution.

When this happens can you SSH into the Vero and see if you can access the share that way?

Yes, PC is powered on, and not in standby. I am using the same PC to ssh into the Vero. I can login successful, but I can’t access the mnt directory via ssh either. So network address is fine, it is just accessing the mount that is an issue.

A reboot of Vero, and mnt is again accessible again via ssh and via OSMC (at least for a while).

Here is my fstab line

//Attic-PC.local/G /mnt/media cifs x-system.automount,noauto,rw,iocharset=utf8,username=#####, password=#####,uid=osmc,gid=osmc,file_mode=0770,dir_mode=0770 0 0`

This has always worked for me perfectly until after the April /May update.

I wasn’t clear. Is the PC ever powered off or go to sleep? fstab mounts are not real tolerant of that.

Are the systems connected to the network wired or wireless?

No. PC is never powered off or in standby.

None of the systems involved are using wifi.

Usually this type of problem is because you are losing network connectivity between the 2 systems.

Can you try leaving a SSH session open from the PC to the Vero and see if the session is lost when the share drops?

And if when the share does drop, try this:

mount

and share the output from that. Then:

sudo systemctl stop mediacenter
sudo umount /mnt/media
sudo mount /mnt/media
sudo systemctl start mediacenter

That should get the share back without rebooting. If the umount fails, try

sudo umount -f /mnt/media

instead.

Ok, I’ll try that tomorrow. It just seems strange that these issues only started after the April/May update. Potentially Leia is handling something differently with mounts like this.

Since you are using fstab mounts, Kodi isn’t involved in that process. It’s handled at system level.

Here is output from mount command. At this point the mount is not accessible in OSMC. You will also notice at the bottom that when I try a directory listing for mnt it does not respond. I need to kill the ssh session at that point.

osmc@osmc:~$ mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=791584k,nr_inodes=197896,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,relatime)
/dev/mapper/vero--nand-root on / type ext4 (rw,relatime,stripe=1024,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/bfqio type cgroup (rw,nosuid,nodev,noexec,relatime,bfqio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
systemd-1 on /mnt/media type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
//Attic-PC.local/G on /mnt/media type cifs (rw,relatime,vers=1.0,cache=strict,username=jeff,domain=ATTIC-PC,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.86.27,file_mode=0770,dir_mode=0770,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=183224k,mode=700,uid=1000,gid=1000)
osmc@osmc:~$ cd /mnt
osmc@osmc:/mnt$ ls

Sudo umount /mnt/media did not succeed.

Here are results with -f

osmc@osmc:~$ sudo umount -f /mnt/media
umount: /mnt/media: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
osmc@osmc:~$

should be x-systemd.automount. But autofs is much more robust.

1 Like

Dud you stop Kodi (mediacenter) before trying the unmount?

The error you got usually means that something is still trying to access the share. It seems like for some reason, you are losing network between the Vero and the PC at some point during the night. Do you have automatic updates enabled on the PC?

Are there any other systems also accessing the PC?

Good catch @grahamh, I missed the typo on the fstab!

If fixing that does not fix the problem, then as @grahamh mentioned, consider using autofs as it will work much better.

It was only a typo entering the line here in the forum. It is correct in fstab.

I really don’t think it is anything to do with the PC. It happens every time I stop using the Vero (not occasionally). Last night it happened within 10 minutes of watching a show on the Vero. It is like there is some kind of timeout.

I have had the same setup for 1.5 years working flawlessly until this recent update.

Was there any changes in Power Saving in this version that may cause Vero to disconnect from the mount due to going into some kind of power saving mode?

I will also try autofs if I can’t figure anything else to get fstab working again. I just really don’t want to have to rebuild my library again (unless it just recognizes the /mnt/media directory the same and Kodi doesn’t even notice the change).

Oh, and yes, I did enter the following line before trying to unmount, and it seemed to work successfully.
sudo systemctl stop mediacenter

If you switch to autofs you can keep the same mountpoint, so Kodi will never know the difference.

There should be no power settings causing this.

Did you try leaving a SSH session open to see if it closes?

You could setup a continuous ping from the PC and see if you get drops when it happens.

I will try leaving SSH open when I am back at home later today. Will let you know the results.

Appreciate all the help. This is a frustrating one :frowning:

Maybe I will try the PC ping. Although, I have never got a drop while watching shows. Only happens when we are not using the Vero and come back to it the next day. As mentioned, I did check last night 10 min after watching a show, and it had already lost connection to mount.

Thanks.

Since the mounts are handled by the system, Kodi would not be causing the share to drop.

I agree with you that this is a strange one.

Are there any other systems accessing the PC via SMB?

No, nothing else accessing the PC, so unfortunately nothing else I can test with.

I had another thought to try… Next time that this happens, stop Kodi

sudo systemctl stop mediacenter

and then see if you can access /mnt/media.