lost access to SMB shares from RPi/OSMC

hairy_mutley

Active Member
I have been using a RaspberryPi as a video server for my HDR-Fox-T2 for some time now.
The RPi has a 4Tb USB drive, is running OSMC and sharing the drive through samba.
The HDR has [ModSettings]/smb to support the samba connection, hence I have been able to select the 4Tb drive via USB to play files from it.

Recently (possibly following the December+January update on the RPi) this has stopped working. Now the HDR rarely offers the shared USB as an option.
If I telnet to the HDR, I can see that every few seconds, the mount point appears briefly in /media.
At the same interval /var/log/scanmounts.log shows...
Code:
Mount failed...
umount: can't forcibly umount /media/osmc_smb: Invalid argument
192.168.0.15 is on-line - attempting to mount osmc_smb
mount -t cifs //192.168.0.15/osmc /media/osmc_smb -o user=osmc,password=osmc,domain=WORKGROUP,unc=\\192.168.0.15\osmc
So, it looks like the HDR end is working. The settings at the RPi end all seem to be as they were previously, but I am unsure how to debug that end.

Note that at my Windows 10 PC, the "Network Locations" shows the RPi in 2 places. A Samba4.2.14-Debian connection to the RPi which also does not work. The troubleshooter just suggest that the problem is at the other end). The connection that I have always used previously is a drive letter mount and this still works (but I don't know what connection mechanism this uses, I thought that it was samba).

Any suggestions on how to tackle this?
Equally, I would use nfs or any other share mechanism if I knew how to get it working.
 
Thanks for the pointer.
OSMC does have an option for setting the maximum samba level which is currently set to samba 3. It implies that this is a maximum negotiated level, so I had assume that it could negotiate down to a lower level if need be. But under the setting there is a comment about some devices needing samba 1 or samba 2.
I had tried setting this to both 2 and 1, might be worth a retry and I will see if I can find any more about how this control operates.
 
The OSMC maximum samba level that I referred to in the last post is not applicable to this problem as is applies to an OSMC samba client.

For me, the solution was as follows (and may apply to connecting any legacy samba client to a post Jan 2018 OSMC samba server). The fix is applied to OSMC (not HDR).

The references talk about editing the OSMC /etc/samba/smb.conf file, but I actually performed all my edits on smb-local.conf. The smb.conf file describes how it should be created by copying and commenting out the include line (hence offering protection from any samba upgrades).
https://discourse.osmc.tv/t/trouble...blu-ray-player-since-december-update/70151/16 fzinken said
...allow weak password protocol
Code:
sudo systemctl stop samba
sudo nano /etc/samba/smb.conf
add the lines lanman auth = yes and ntlm auth = Yes
Code:
sudo systemctl start samba
The auth lines need to be added in the [global] section of the file.
A linked post also said...
Please remove the:
TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
settings. They are voodoo left over from Samba and Linux kernels of the 1990’s. Modern Linux and Samba will only be hurt by forcing these settings.
I just commented out the whole socket options line.
 
Back
Top