Samba is not working

as would I, though the only thing I have altered is the .conf file. This is, I assume, easily restored from the backup fzinken directed me to create. So I am happy enough until Sam works it out

What did you change in the conf file to get it working?

Unfortunately I can’t replicate this problem here, so I am hoping someone with a bit of time can go through the file and find the offending setting which is causing the issue. Then we can fix the issue for all users.

Sorry, altered was a poor choice of words, swapped would be more accurate.
As fzinken suggested I backed up smb.conf to smb.conf.osmc
then copied smb.conf.distributed as smb.conf

Got you.

We need to find the culprit in the configuration file we distribute (with some trial and error, no doubt), then I can fix the issue for all users.

ok, did some poking in the original smb.conf and found if I comment this line out:
# usershare template share = automount template
mounting via fstab works again
don’t know where to go from there, hope that sheds some light?
let me know if there’s another file I can poke around in


Thanks for narrowing that down.

@fzinken Can you confirm if this resolves the issue for you?

The automounting of shares via SMB was written by @DBMandrake. I’ll need to catch up with him on this and discuss the significance of this. But it’s Christmas and he is a bit busy lately, so it might be a little while until I get a chance to talk to him about this.

Thanks again for the investigative work. I’ll work on reproducing this locally.


Yes, just commenting that out makes it work

1 Like

This worked also for me!

I commented that line as @Spasmodean suggested, and now everything is working as usual again.


I am getting the same error as reported. The thing is that I only have it on the automounted shares, neither in [osmc] nor in the [home] shares.

Reading around, I have found this Ubuntu error, that might be related if that update also went into Debian. I am not sure if that is the root cause of it.

I don’t believe the Ubuntu bug is related (given the time frame)

Unless they have dropped a still needed patch in the last security update (see previous upload, not the security one, it dropps two regression patches for the security upload for the CVEs that is referenced in the Ubuntu bug.

samba (2:4.2.14+dfsg-0+deb8u2) jessie-security; urgency=high

  * This is a security release in order to address the following defects:
    - CVE-2016-2123 (Samba NDR Parsing ndr_pull_dnsp_name Heap-based Buffer
      Overflow Remote Code Execution Vulnerability).
    -  CVE-2016-2125 (Unconditional privilege delegation to Kerberos servers in
      trusted realms).
    -  CVE-2016-2126 (Flaws in Kerberos PAC validation can trigger privilege
  * Fix smbclient compatibility with Windows 10 (Closes: #820794)

 -- Mathieu Parent <>  Thu, 08 Dec 2016 21:12:25 +0100

samba (2:4.2.14+dfsg-0+deb8u1) jessie; urgency=high

  * New upstream release.
   + Fixes CVE-2016-2119: Client side SMB2/3 required signing can be downgraded.
   + Various fixes for regressions introduced by the 4.2.10 security fixes.
   Closes: #820965, #827141
   + Fixes for segfault with clustering. Closes: #824177
   + Bump tevent dependency up to 0.9.28.
  * Drop obsolete patch security-2016-04-12-prerequisite-v4-2-regression-
  * Drop patch sockets-with-htons.patch; applied upstream.
  * Drop patch CVE-2016-2110-NTLMSSP-regression.patch; fixed upstream.
  * Drop patch s3-smbd-fix-anonymous-authentication-if-signing-is-
    m.patch: fixed upstream.

 -- Jelmer Vernooij <>  Sun, 04 Sep 2016 14:21:35 +0000

I’ll ping the Samba maintainer.

We need to discuss this with them, and this won’t hurt to bring up


I think I am also seeing this same problem. After the December update the issue was manifesting as:

Non-Windows clients (e.g. several iOS apps) were not able to connect to the auto-mounted shares. The OSMC directory worked fine for iOS clients. Windows clients could connect to all shares including the auto-mount (which is probably why a lot of people aren’t noticing this).

My samba logs look like the ones posted here (I can post them if you want, but they look the same) with a signal 11 and smb_panic at the times the non-Windows clients tried to connect.

Commenting out the auto-mount template and manually adding an entry for my external usb drive and everything works again for all clients. This is fine as a work around for my use cases.

Hopefully this use case can help in identifying the underlying problem.

It’s been very busy around here, but I’ve finally reported this to the Samba maintainers for Debian. I’ll keep you posted as things progress.

Debian 8.7 landed in OSMC’s January update. I didn’t get a chance to check yet, but can someone revert the changes and check that there are still problems?


I’ve applied the January update but unfortunately the issue still persists if
usershare template share = automount template
in smb.conf is not commented out.

All working fine when it is commented out.


Stumbled on the same problem here today and this workaround works for me as well.

Please help. I have two RPi3’s running in separate rooms and one of them (lets say RPi#1) has Samba running and a powered external drive attached via USB for sharing media files. After updating to Krypton (on both RPi’s), RPi#2 gets an error (“Software caused connection abort.”) when I try to connect to RPi#1. I enabled Samba on RPi#2 and have no problem connecting to it with RPi#1 or my Windows pc. Any ideas on this?

Here is the log file I copied after the error occurred …

The answer is just a few posts up in this thread. Edit your smb.conf file and comment out the line advised.

This worked out great, thanks for the assistance.

Thank you.