lmatte's picture

I'm aware that latest Windows 10 systems disable SMB1 protocol, but even re-installing its support in a Win10 pro machine I'm using the access to fileserver is still impossible -- results in "error in name or password".

Moreover, this latest Samba 4.5.12 shouldn't already be ready for SMB3 as the 3_11 used by Win10?

Note that I didn't add anything to standard TKL 15 smb.conf (where a few shares are already defined), just a regular user for access -- and if I'm running 'smbclient' on the TKL box looks like it's fine...

Maybe I'm simply confused, as I think an incompatibility with basic Win10 access should have become a common documented fix... -- what I find searching the net is just around SMB1/SMB2 issues, which I'm not sure now is the problem

 

Forum: 
Jeremy Davis's picture

I'm not 100% sure, but I suspect that the issue is to do with the Samba/Linux user accounts (particularly passwords) not syncing. Unfortunately, it's a known issue without a super easy workaround. The sync Linux Samba users functionality was removed from newer versions of Samba due to security concerns and they have no plans to reintroduce it. The current workaround is create your new users via the commandline and ensure that they have both a Samba password and a Linux password. I don't have the exact command(s) handy sorry, but will look into it ASAP.

I really need to have a closer look at our fileserver appliance and see how I might be able to improve it. As of Samba4, we don't actually need to create a separate Linux user for Samba users, but our current Fileserver appliance provides numerous other ways to access files, some of which DO require a Linux user. And the original point of it was that user's files could be consistently access via various methods, regardless of which style user account was in use. We'll likely have to review that and perhaps consider splitting the FIleserver in two. Or at least making the limitations clearer.

Out of interest, have you tried to log in via the preconfigured root user? (Should be able to log in using username "root" and the password you set at first boot). If that works, that will at least confirm my suspicions. Alternatively, if it doesn't work, then it may confirm yours.

Jeremy Davis's picture

I've finally carved out enough time to have a quick test of this, and my preliminary testing suggests that my initial guess is likely correct.

I've just done a clean install of TurnKey v15.0 Fileserver. Using the pre-configured "root" account, I can connect to that fine from Windows 10 Home edition with all the latest updates installed. FWIW I simply opened Windows Explorer, typed "\\192.168.1.70" (i.e. the IP of my fileserver) and entered the username "root" and password (that I set at firstboot) and I'm straight in.

FWIW though, this wasn't a clean install of 10. It was an upgrade install from Windows 8. So there is a chance that is a factor (some settings from Win 8 being retained from the upgrade?). Although I don't really have anyway of knowing whether that's a possibility or not?!

Regardless, it seems likely to me that this is not an issue with default configuration, but the user account setup that I alluded to previously (i.e. Linux user passwords not being synced with Samba/Windows user passwords). I'll do a little more testing and post back as soon as I can confirm.

Jeremy Davis's picture

So assuming that there aren't any left over config from Win8 on the machine I'm using to test, then it definitely works with new users. But the required setup is certainly a little clunky and could do with improvement.

So let's assume that you are happy to keep the existing share set up. I.e. the user's home (/home/USERNAME) is owned and only accessible by the user, the cdrom is read-only by all users, and storage (/srv/storage) is readable by all users, but writeable only by root.

In this initial scenario, all we want to do is create a new user who will have access via SMB shares (i.e. Windows shares), no access via their Linux user (so no usage of SFTP, etc). To do that:

smbpasswd -a USERNAME # '-a' only required if user doesn't already exist

Note the '-a' switch is to add a new user, if the user already exists, this can be omitted. Then follow the prompts to set their password (enter once, then confirm). E.g. to add new user 'test1':

root@fileserver ~# smbpasswd -a test1
New SMB password:
Retype new SMB password:
Added user test1.

If you wish the user to also have access via their Linux user account (e.g. via SFTP), you'll need to set a password for that. Use the 'passwd' command:

passwd USERNAME

The steps are similar, enter the command, then set and confirm the password. E.g.:

root@fileserver ~# passwd test1
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

I won't go into it now because it's well out of scope of this post, but please be careful allowing users access via SFTP. OTTOMH there are 2 main considerations:

  1. It also allows them shell access by default. Under normal conditions the user is quite locked down, but it is certainly a security consideration. Ideally best to give them a shell of '/usr/sbin/nologin' or '/bin/false'.
  2. It's also worthy of note, that whilst they won't have write access across the filessystem, they can browse about (they will sftp into their home by default - but can browse outside it). So you may also wish to config a "chroot jail" for them (out of scope of this post).

If you ever wish to update the passwords, just call the 'passwd' or 'smbpasswd' commands as appropriate (depending on whether you wish to update the Samba of Linux passwords). Note that when resetting the password of an existing Samba user, you do not need to use the '-a' switch.

Any users who you wish to have write access to the "storage" share (or any other share which is has "read only = no" in /etc/samba/smb.conf), then you'll need to add them to the 'sambashare' group. That's also pretty straight forward using the 'usermod' command. I.e.:

usermod -a -G sambashare USERNAME

So in the case of my "test1" user:

usermod -a -G sambashare test1

Now my new user can view available shares via Windows Explorer and can wrote to both their home and also to "storage" (/srv/storage on your Fileserver).

Other than that particular quirk regarding Samba user passwords, you should find plenty of relevant info online about configuring Samba. Please note though, that by default the config we provide is not relevant to AD domains.

I hope that helps.

Any other questions, please feel free to ask. Also please share anything interesting that you discover in your travels, you'll likely save others effort in the future.

lmatte's picture

My previous reply here got lost someway...

Whatever, I already tried root access, and resetting passwords both with 'smbpasswd' and 'passwd', but none of them worked, with two Win 10 pro systems - one coming from a Win 7 pro update, the other from a fresh Win 10 pro install; both updated to latest updates version 1809.

I understand very well how it's hard to follow which is which on W10 installations, but both systems with a similar behavior make me think there's a common cause - just don't know what and how to track it

 

lmatte's picture

I connected a Linux machine on the same net, running Peppermint 9 (reports Samba "4.7.6-ubuntu", basic installation), and correctly connects to TKL Fileserver, so the user is proper.

The Peppermint Linux device connects also to the W10 ones, up to now it looks like the W10 -> TKL Fileserver is the only connection failing authentication

 

 

lmatte's picture

Since my TKL Fileserver is a fresh install in a Proxmox container, I quickly deleted and reinstalled it, with the least intervention possible.

On install Proxmox creates the root access with a given password, and that's fine. Let's say I used 'foo2019' on my new instance IP 192.168.0.101

When I access on SSH telnet (root, password 'foo2019') for first time the setup asks me to set Samba root user password: I chose 'bar2019' (note this).

Win10pro machines still don't see the server at all, not even browsing the net.

From the Linux client I then browse smb://192.168.0.101, login as 'root', but only password 'foo2019' works: what was password 'bar2019' for?

I'm a bit confused

 

lmatte's picture

Ok, maybe was just a mistake: the second password is enabled for shares, not the first used for root

Jeremy Davis's picture

I'm not sure if it was a factor or not, but I've just tweaked your user account to avoid the majority of the spam traps. That should make posting a little better/easier/more reliable.

With regard to your issues, first up, I was using a "proper" VM for testing (rather than an LXC container). I'm not sure what impact that may have but perhaps that is a factor regarding your problems? LXC does have some idiosyncrasies for some specific software and Samba may well be one. I do have a fileserver appliance running as an LXC container on Proxmox too, but it is running a much older version and I never use SMB on my network anyway, so didn't test with that (as it seemed likely irrelevant).

As your (updated) comment notes, regarding the "root" user, the password that you set prior to container launch (i.e. 'foo2019') is for the Linux user only. The Samba user password is set (separately) at first boot and unless you explicitly set the same password during that firstboot initialisation, it will be different.

FWIW when using a "proper" VM, that is not the case (they use a consistent password). That is only because both passwords are set at the same time (i.e. both smbpasswd and passwd are run using the same password that you input). That is because, on an LXC container the root password is set via the host prior to launch, and there is no way to decrypt the existing password, hence why the Samba password needs to be explicitly set.

Still, this doesn't really answer why you are unable to access via another Samba user as I was able to?! My suspicion is that it is related to the password as I noted in my previous post, but I can't be 100% sure.

Perhaps there is some setting within Windows Pro which isn't applied (at least by default) within Windows Home? Perhaps some security setting that is more locked down? Unfortunately, I no longer have the laptop, so I can't 100% confirm the build number, but I did definitely run Windows update and installed all outstanding updates (last check I ran stated "no updates") so I would assume that was the most recent version.

Although if you can access the "root" Samba user now, I'm not really convinced that that is an issue. Other than the level of permission to the filesystem, there is no fundamental difference between the default Samba user (i.e. 'root') and any new users that you create.

I'll see if I can get hold of a Win 10 Pro machine and test from that.

lmatte's picture

Jeremy,
thanks for supporting and testing. I will try with a Win 10 home system that I should be able bring here, in the next days.

Luca

Jeremy Davis's picture

You're most welcome! :)

Also it seems likely that I will be able to get hold of a Win10 Pro machine next week. Assuming it comes through, this particular machine was a clean install about 12 months ago (according to my source anyway). Hopefully that should provide us with some additional info.

lmatte's picture

Finally had a chance to test a Win 10 home laptop, and it works: connects successfully, as it does the Linux laptop. Win 10 pro machines keep failing saying "password isn't correct".

Luca

 

Jeremy Davis's picture

I wonder what is going on in the Win 10 Pro clients? I still haven't had a chance to check myself with Win Pro, but I wonder if it's some sort of policy issue on your machines? Are your Win 10 machines connected to an existing AD domain? If so, perhaps you need to join the fileserver to the domain first?

lmatte's picture

Nope, no active directory, just Win10 pro clients with the minimum to use SMB/CIFS networking.

Note however that something changed in the latest (Windows) updates: previously I had an older TKL 13(?) fileserver that worked smooth with the same W10pro clients. After some (long) time that I wasn't using that server I tried reconnecting and found something was broken: the clients couldn't connect anymore. As it was time to update the server, I freshly reinstalled the latest, and here I am (...)

 

Jeremy Davis's picture

I'm not 100% sure, but I've just been doing some reading. TBH, it doesn't explain why latest Win 10 Home works, but Pro doesn't, but it may just be a case of Pro having tighter defaults?

I'm not sure if this is the issue you're hitting, but it seems that under some specific circumstance (which I'm still not completely clear on) newer versions of Windows Pro may not play nice with slightly older versions of Samba. It seems that there is an issue with the version of the SMB protocol that Windows tries to use (SMB3_11) that Samba doesn't support. Samba does support SMB3, but not the latest (SMB3_02 is as high as it goes). AFAIK both Samba and Windows should be quite happy to use SMB3_02 and by default, Samba and Windows should be able to negotiate a protocol version that they can both work with (I would assume SMB3_02). But for some reason that doesn't happen?! Perhaps there is some setting within Win Pro that is stopping the downgrading of protocol. So vague info I found via google suggests trying to force Samba to use SMB3 off the bat. I.e. within your smb.conf, look for under the [global] section and define the minimum version of the SMB protocol to use SMB 3 (edit the line that should be there already):

[global]
client min protocol = SMB3

You'll need to restart Samba to apply the settings. There are also settings for 'server min protocol' & 'client max protocol' which might be worth playing with if it still doesn't work?!

If that still doesn't work, the only other thing I can suggest, would be to try allowing Win 10 to downgrade the version of SMB it will allow. If that still doesn't do the trick, then I guess we can assume that was a dead end, and try something else...

lmatte's picture

Well, I'm pretty sure I already fiddled a bit with min/max protocol on the first install, as I read the manual for smb.conf, but even those tests weren't going anywhere.

I tried again, and setting a range of valid protocols still didn't return a valid result.

Note that I already read some notes on dropped SMB1 protocols in Win10, and how to reinstall them. So I did too, but even that didn't help. Even worse, I'm sure that on first try I could browse the network and see the fileserver from Windows Explorer, while now I must type destination as "\\fileserver", otherwise isn't browsed at all (...)

I still hope to find someone who's fixed this Win10/Samba connection, and I'm quite sure there's a solution somewhere, as Samba can't be unable to operate with latest Win10! In this (long?) while my fileserver will stay down...

Jeremy Davis's picture

TBH I'm pretty much at a loss...

The fact that Win 10 Home can connect but Win Pro can't, suggests to me that it is some setting within Win 10 Pro that is stopping it from working. The only other thing that occurs to me is if you have some security policy set that it interfering with it?! Do you have any policies set up at all? Even if you don't think you have, perhaps it's worth double checking anyway?! If you're not sure how to do that, here's a link to an article I found which looks promising.

I still haven't been able to get hold of that Win 10 Pro machine I mentioned previously, but I'll continue to try to get hold of it and double check from my end. If it's a setting in Samba that we can adjust which will make it work better (ideally without breaking it for other users) then we'll certainly look into that.

Sorry that we haven't been able to work out what the issue is... :(

ekym's picture

I just was reading this thread and thought it couldn't hurt to mention that I just last night,  installed the proxmox with the fileserver CT and I have no problems connecting to it from any windows 10 pro VM, laptop, desktop also connect to it from ubuntu, debian, mojave

I will note that it seamed dependant on the correct domain name, and that so far it seams not dicoverable from any system. You do need to browse to it and know the address. 

Jeremy Davis's picture

Thanks very much for posting.

It is really good to get confirmation that the appliance should be working - even with Win 10 Pro. It's also useful to understand that you need to explicitly browse to the server to connect.

I'm still stumped on what may be the cause of lmatte's troubles though...

lmatte's picture

What confuses me even more is that on first install of fileserver I actually could browse it from a Win10 pro machine.

What's changed since then? Well it disappeared when I did restart the Win10 client, maybe: after that I tried reenabling SMB1 on W10 and I did some foo, bar, baz, etc. Really: can't remember anymore what I tried, checked policies and made some changes read on MS support channels.

But even the second device I tried, a W10 pro laptop, with no modification to a configuration that in the past worked with Samba, didn't browse the server.

Oh well, and I didn't configure any domain on W10. On W10, AFAIK, there's no clear configuration that you can do in a single file, like editing 'smb.conf'. From experience with Windows networling in the past I could also tell that sometimes if you just wait device start seeing each other, with no clear reason. It's all that erratic. I'm quite fed up, I think I will try again with next brand new W10 computer, and give in with the current ones.

Thanks anyway for supporting, at least now I know it's a local behavior.

 

Jeremy Davis's picture

Weird idiosyncratic behaviour, limited to specific machines (which in theory should have been the same as other ones that worked) was the bane of my existence when working as a Windows Sysadmin (years ago for a small local NGO). MS have certainly got much better on many fronts in more recent times, but I still love the way that Linux in general, but Debian in particular "just works" (or just doesn't - with mostly useful error messages). I also love the simplicity of text file config (no registry and/or GPO stuff).

Although in fairness, I don't maintain a network of Linux machines with multiple users, so I'm not really comparing apples to apples. Also, in your scenario, we're mixing Windows and Linux, which again is not completely fair to blame exclusively on Windows. Whilst MS did supply some docs for Samba4 devs, most of it is still reverse engineered AFAIK.

Regardless, I'm really sorry that we couldn't get this working. If you ever work out what the issue is, please share.

Add new comment