I am having problems on a single Tumbleweed computer concerning SMB authentication. My other SUSE boxes run Leap 42.3 and are problem free. The problem is recent, possibly caused by an update? I had run Tumbleweed for months without issue. The problem is as follows:
I use AJC Directory sync on a Windows 8 machine to do all my backups on both Linux and Windows computers. I have used it for years. I am unable to log into my Tumbleweed machine with my credentials using AJC. What makes it unusual is that I am able to authenticate correctly into Tumbleweed with Windows Explorer and can also authenticate with SFTP using either AJC or Filezilla.
Something additional that may or may not be related is TeamViewer. From Windows or one of my LEAP machines, I am unable to connect to TeamViewer on my Tumbleweed machine directly by LAN, but can connect correctly via the TeamViewer server. On the other hand, from my Tumbleweed machine, I am able to connect to any of my other computers directly via LAN.
The SMB settings are correct as far as I can tell, since I can log in with Windows Explorer from the other machine. My TeamViewer settings are also correct as far as allowing incoming LAN connections.
I have myself set up as a Samba user and it’s the same as my local user account. Using Windows Explorer in Windows 8.0 when I click on a Samba share of my Tumbleweed box, I am presented with an authentication window for user name and password to log into the share, which is 100% successful every time. When I click on the same Samba share with AJC in Windows, I am given an authentication box identical to the one that Windows Explorer gave me. When I give my credentials, they are rejected every time.
I’ll post the pertinent parts of my samba.conf file, but it is pretty much identical to my Leap machines, which AJC has no problem logging into:
[global]
workgroup = Bailey
netbios name = Ryzen7
server string = ""
preferred master = auto
passdb backend = tdbsam
name resolve order = bcast host lmhosts wins
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
use client driver = yes
map to guest = Bad User
local master = yes
os level = 33
usershare allow guests = No
usershare owner only = True
[ronnie]
read only = No
inherit acls = Yes
path = /home/ronnie
[windows]
read only = No
inherit acls = Yes
path = /windows
I just did a “zypper dup” and Samba was among the updates. If I do not post back shortly, it is safe to assume that the problem still exists.
Recommend doing a manual mount of the network share on your Windows box.
If you can mount and access shares successfully, then the problem is in your AIC sync app.
That would make sense, but it’s hard to understand why AJC can authenticate correctly with my 2 Leap boxes and only fails when trying to authenticate with my one Tumbleweed box. I am guessing that my Windows version is part of the problem. I am stuck with Windows 8.0 on that machine since my Opteron CPUs are not compatible with NX instructions. Windows 8.1 requires it. Microsoft only provides newer versions of .NET for either 7 or 8.1 and nothing is available for 8.0 which may be part of the problem since AJC is from August of this year.
Actually, AJC Sync is the only reason that I use Windows for anything. It is quite user friendly and configurable. Guess I’d better bite the bullet and get a much better understanding of rsync.
I very much appreciate the responses.
Still no joy. I’ll post the output of what wireshark saw as I tried to get AJC to connect. I have no idea if it is caused by the type of authentication or some wildcard setting that that breaks things. I have my samba.conf file set to authentication = user
SMB2 Header
Server Component: SMB2
Header Length: 64
Credit Charge: 1
NT Status: STATUS_LOGON_FAILURE (0xc000006d)
Command: Session Setup (1)
Credits granted: 1
Flags: 0x00000001, Response
Chain Offset: 0x00000000
Message ID: Unknown (3)
Process Id: 0x0000feff
Tree Id: 0x00000000
Session Id: 0x000000000b9d9766 Acct:ronnie Domain:HAL-3 Host:HAL-3
[Account: ronnie]
[Domain: HAL-3]
[Host: HAL-3]
[Authenticated in Frame: 1183]
Signature: 00000000000000000000000000000000
[Response to: 1183]
[Time from request: 0.000866688 seconds]
One thing that sticks out to me is that it is showing my Windows 8 box as a member of domain HAL-3 when it is not a domain member and that domain does not even exist.
I have tried installing AJC on a Windows 7 box and a Windows 10 box. Under Windows 10, it can log into my “home” share and it does not show a domain name in the authentication pop-up, but I cannot access what I call my Windows drives where I keep my backups. The directory for them is /windows which means it is under root, but it has always worked before. I have made myself owner of that directory and all below it and the group is “users”, with myself having full access.
All Linux boxes communicate with each other well as do all Windows boxes. All shares work between machines with the same OS. I find tons of advice via searches, but nothing has worked.
Whenever I run into a problem described generally as you have, ie Can see or use some part of a network share but not the whole thing,
it’s almost always related to the Share permissions and the File permissions… On any and all Servers, this problem can occur the same way, the User permissions to the resource is a calculated combination of the two ways that permissions are set.
To avoid this, my SOP on the Server where the shares are deployed…
All Shares are deployed in the same directory tree if possible so that special settings for network shares are all in the same place
Tree file permissions in this specific location is set to Anonymous for everything you want to grant for the remote network User… read, write, remove, full, whatever(Of course, still be aware of any dangerous settings). This is critical because only Anonymous enables full and clear implementation of whatever you set in the following…
Now with File Security no longer something that can affect, set your Network Share (eg Windows Sharing or SAMBA) permissions as desired. Whatever you set will be effective and not be polluted by combination with a File Permissions setting.
If the above is implemented, I’ve never seen an unexpected result.
Of course, if you want to more securely lock down network shares, you can or should set file permissions and maybe start by creating at least one special “Network Sharing” group configured as you wish. Setting anonymous file permissions can be a big problem in some scenarios which is why at the very least I recommend that this be configured on dedicated File Sharing servers only and not multi-use servers… And no one of course should be doing anything that can expose this machine to malicious threats.
I do have an additional question. This may be a bug. If I use the “share” tab under file properties with Dolphin, even under su mode, the settings do not stick. If I go back to check permissions, the share tab is blank again. I know how to chmod and chown with a terminal, but do not know sharing commands.
As far as “Anonymous” is concerned, are you talking about the owner of the files? I am not sure I understand.
tsu2, I was going back over your post and I think that you misunderstand my problem. I can authenticate and access 100% of my shares on all my Windows boxes using Windows Explorer.
The problem that I have is that I am unable to access any of them with the Windows program that I use for backups. The program’s author states that the program uses Windows features for share access. When I try, I am presented with a popup that looks identical to the popup that Windows Explorer uses for authentication, but my credentials are rejected every time. But with that same program, I am able to access shares on my Windows boxes. The messages I see using Wireshark and SMB4k are:
NT Status: STATUS_LOGON_FAILURE (0xc000006d) and
Failed to open /var/lib/samba/private/secrets.tdb
The secrets.tdb and passdb.tdb files are there, but they are “read only” for root and “forbidden” for all others.
I guess your AJC client was impacted by this change…
Samba 4.5.0
Release Notes for Samba 4.5.0September 7, 2016 Release Announcements
This is the first stable release of the Samba 4.5 release series. UPGRADING
NTLMv1 authentication disabled by default
In order to improve security we have changed the default value for the “ntlm auth” option from “yes” to “no”. This may have impact on very old clients which doesn’t support NTLMv2 yet.
The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x.
By default, Samba will only allow NTLMv2 via NTLMSSP now, as we have the following default “lanman auth = no”, “ntlm auth = no” and “raw NTLMv2 auth = no”.