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.

Add new comment