Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: p-jones on November 23, 2018, 10:28:25 AM
-
W10 PC's that were happily talking to SME shares stopped working directly after the last updates.
Anyone else experiencing same and anyone found a fix ??
Thanks
-
What does "stopped working" means ?
-
Anyone else experiencing same and anyone found a fix ??
Thanks
No not experiencing same - Win10- Home
-
What do your logs tell you?
Always the first thing to do.
-
What does "stopped working" means ?
Network browser can see the server exists but when drilling down to the ibays, produces an error which translates to the server not accepting connections.
Logs show nothing. (first place I looked). W10 SMB1 is OK and IMAP email is OK. HTTPS is OK. No problems until immediately after last updates. I suspect something going on with Ports 138, 139 445
-
Last updates as in SME or Wimdows?
What do the server logs say?
-
Also show
config show smb
Are you using domain logon or straight foward shares?
What additional contribs are installed?
-
Last updates as in SME or Wimdows?
What do the server logs say?
Last updates to SME Server
-
Note this was the last patch for samba
https://bugs.contribs.org/show_bug.cgi?id=10575
What is in your smb.conf?
-
Also show
config show smb
Are you using domain logon or straight foward shares?
login as: root
root@192.168.2.15's password:
Last login: Fri Nov 23 20:07:43 2018 from 192.168.2.73
************ Welcome to SME Server 9.2 *************
Before editing configuration files, familiarise
yourself with the automated events and templates
systems.
Please take the time to read the documentation
http://wiki.contribs.org/Main_Page
Remember that SME Server is free to download
and use, but it is not free to build
Please help the project :
http://wiki.contribs.org/Donate
****************************************************
[root@server2 ~]# config show smb
smb=service
ClientMaxProtocol=smb2
DeadTime=10080
KeepVersions=disabled
OpLocks=enabled
OsLevel=35
RecycleBin=disabled
RoamingProfiles=no
ServerMaxProtocol=smb2
ServerName=server2
ServerRole=PDC
ShadowCount=10
ShadowDir=/home/e-smith/files/.shadow
UnixCharSet=UTF8
UseClientDriver=yes
WINSServer=192.168.x.x
Workgroup=xxxxxx
status=enabled
[root@server2 ~]#
straight forward shares
-
Interesting as mine don't have MaxProtocol set (but I have no Windows to test.... Terry might be about later)
smb=service
DeadTime=10080
KeepVersions=disabled
OpLocks=enabled
OsLevel=35
RecycleBin=disabled
RoamingProfiles=no
ServerName=home
ServerRole=PDC
ShadowCount=10
ShadowDir=/home/e-smith/files/.shadow
UnixCharSet=ISO8859-1
UseClientDriver=yes
Workgroup=workgroup
status=enabled
Did you add the MaxProtocol yourself as I don't think the rpm did that? It might be they need being in caps eg SMB2 ??
Might be worth removing the two entries, post-upgrade & reboot.
Check
cat /etc/samba/smb.conf
Also try testparm and the smbclient test in the bug.
-
OK,
1 I didnt add them myself
2 Changing to capitalised did NOT help
3 Removing with delprop command RESOLVED rhe issue
-
Phew.....very time poor this week.
Thanks for the pointers
-
OK glad we got it sorted.
I'll go back and look at the bug as I'm nit sure how this occurred.
Can you please show:
rpm -qa | grep samba
-
And then I can continue my evening with our friends ;-)
-
[root@server2 ~]# rpm -qa | grep samba
samba-common-3.6.23-51.el6.x86_64
samba-client-3.6.23-51.el6.x86_64
e-smith-samba-2.4.0-26.el6.sme.noarch
samba-winbind-3.6.23-51.el6.x86_64
samba-winbind-clients-3.6.23-51.el6.x86_64
samba-3.6.23-51.el6.x86_64
[root@server2 ~]#
-
Thanks. I'll revisit the bug.
Please keep an eye on this thread and add yourself to the bug.... be handy if you can help test things if we modify it.
-
Win10 Home PC
My Home server config and should also add fully updated
[root@fagehome ~]# rpm -qa | grep samb
samba-winbind-clients-3.6.23-51.el6.x86_64
e-smith-samba-2.4.0-26.el6.sme.noarch
samba-client-3.6.23-51.el6.x86_64
samba-common-3.6.23-51.el6.x86_64
samba-3.6.23-51.el6.x86_64
samba-winbind-3.6.23-51.el6.x86_64
[root@fagehome ~]# config show smb
smb=service
DeadTime=10080
KeepVersions=disabled
OpLocks=enabled
OsLevel=35
RecycleBin=disabled
RoamingProfiles=no
ServerName=FAGEHOME
ServerRole=PDC
ShadowCopy=disabled
ShadowCount=10
ShadowDir=/home/e-smith/files/.shadow
UnixCharSet=UTF8
UseClientDriver=no
Workgroup=TF_SL
status=enabled
-
See: https://forums.contribs.org/index.php?topic=53587.0
and
https://bugs.contribs.org/show_bug.cgi?id=10575
-
OK,. further investigation:
SME9.2 clean install as at before last round of updates, all confs at default
[root@smei386 ~]# rpm -qa e-smith-samba
e-smith-samba-2.4.0-25.el6.sme.noarch
[root@smei386 ~]# config show smb
smb=service
DeadTime=10080
KeepVersions=disabled
OpLocks=enabled
OsLevel=35
RecycleBin=disabled
RoamingProfiles=no
ServerName=smei386
ServerRole=WS
ShadowCount=10
ShadowDir=/home/e-smith/files/.shadow
UnixCharSet=UTF8
UseClientDriver=yes
Workgroup=sme-server
status=enabled
Latest update applied to SME9.2
[root@smei386 ~]# rpm -qa e-smith-samba
e-smith-samba-2.4.0-26.el6.sme.noarch
[root@smei386 ~]# config show smb
smb=service
DeadTime=10080
KeepVersions=disabled
OpLocks=enabled
OsLevel=35
RecycleBin=disabled
RoamingProfiles=no
ServerName=smei386
ServerRole=WS
ShadowCount=10
ShadowDir=/home/e-smith/files/.shadow
UnixCharSet=UTF8
UseClientDriver=yes
Workgroup=sme-server
status=enabled
-
I think the MaxProtocol options may have been added whilst trying to get around the Win 10 issues originally.
They may have originally been ignored, but the updated rpm then took them into account.
That then advised Win 10 that other protocols (SMB V1/2 over NT1) were enabled and somewhere that caused an issue.
Removing smb2 (which I think should be SMB2 but needs checking with testparm) put it back to NT1 and sanity was restored.
That's my guess anyways.....
Need to see smb.conf before and after to really know.
The remaining question is why did it fail if SMB1/2 was installed on the clients?
Assuming I have this about correct....
Terry, can we go back on the bug and test a little more?
-
ClientMaxProtocol=smb2
ServerMaxProtocol=smb2
These two settings were suggested as possible solutions to the ongoing issue with samba shares and windows 10 from the windows updates in late 2017 and early 2018 that borked win10.
I tried them and plenty of others :-) the above didn't work and I removed them from my smb.conf
If you read the bug quoted the latest update actually fixed a misnamed config entry that enforced the above settings IF they were present.
However they had to be present and the only way for them to be present was for them to have been added manually with, notice the case, lowercase is/was not correct:
config setprop smb ServerMaxProtocol SMB2
config setprop smb ClientMaxProtocol SMB2
The latest update does what its supposed to do, enforces the smb settings :-)
and as to what Mister MS does, mate win10 users, me, have just spent almost 12 months chasing updates to fix an issue that Mr MS introduced with one of his feature updates late last year :-) it has only been the most recent one that has returned the functionality that we already had !!!
Added after hitting enter: They are valid smb.conf settings for any app that needs those protocols
-
Either W10 update 1903, 1909 or both break this again, but can be fixed by also adding port 445 to samba like this
config setprop smb SMBPorts 139,445
-
SME9 - https://bugs.contribs.org/show_bug.cgi?id=10970
and
SME10 - https://bugs.contribs.org/show_bug.cgi?id=10963
Packages waiting for final release
-
Just adding to have a good look through the bugs, plenty of info for bothe sme9 and sme10, when smb1 is dropped from windows you lose ability to browse for a linux share in windows explorer and the listing of same under Network.
There has been work done by ReetP and a tweak or two by JPP on a package incororating the work done here - https://github.com/christgau/wsdd - this enables the display of linux resource/share and browsing of same once again using the wsdd Discovery Method and not netbios which is disabled with the dumping of smb1, This may be making its debut as a contrib soon.
-
by having max protocol set you change samba behaviour from max nt1 (=smb1) to allow smb2. windows 10 then try to connect to higher available. which is smb2. negociate it using netbios port then communicate on 445.
if samba is not allowed to communicate on this port in its config then connexion fails.
a patch is coming around for that, but as pointed above if you want you can force the port.