Win 10 client cannot connect to SMB share

[johnswenson1]

This is my first time with TrueNAS. I just built a Supermicro small server, installed TrueNAS 12, created a pool (Z2). Created a user named servershare, gave it a password. Created a dataset set the owner to servershare. Went through the tutorials set the ACLs to what they said. Created an SMB share following the tutorials.

The Win10 machine sees truenas, when I try and map a drive a popup comes up asking for username and password, type them in, it comes back saying user does not exist.

I looked in the auth_audit.log, servershare is mentioned in there so it looks like windows is sending the name, but there is a status of NT_STATUS_NO_SUCH_USER.

I looked in the etc/passwd and etc/master.passwd and servershare does not show up in either file. Is it supposed to or does truenas use some other way of storing user names? Is the fact that servershare is not in the passwd file the problem?

I've used samba shares in several linux systems before and never had an issue like this.

Anny hints would be appreciated

Thanks,
John S.

 

[anodos]

There are three places to check for your new user:

1) our config file. Example query midclt call user.query '[["username", "=", "smbuser"]]'

Code:

root@homenas[~]# midclt call user.query '[["username", "=", "smbuser"]]'
[{"id": 34, "uid": 1000, "username": "smbuser", "unixhash": "<redacted>", "smbhash": "smbuser:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:<redacted>:[U          ]:LCT-5C139A74:", "home": "/mnt/dozer/homes/smbuser", "shell": "/bin/csh", "full_name": "smbuser", "builtin": false, "smb": true, "password_disabled": false, "locked": false, "sudo": false, "microsoft_account": false, "attributes": {}, "email": "smbuser@microsoft.com", "group": {"id": 41, "bsdgrp_gid": 1000, "bsdgrp_group": "smbuser", "bsdgrp_builtin": false, "bsdgrp_sudo": false, "bsdgrp_smb": true}, "groups": [50, 43], "sshpubkey": null, "local": true, "id_type_both": false}]

If you don't see it here re-add through GUI.

2) "getent password" getent passwd smbuser

Code:

root@homenas[~]# getent passwd smbuser
smbuser:<redacted>:1000:1000:smbuser:/mnt/dozer/homes/smbuser:/bin/csh

If you don't see it here, run command midclt call service.restart user

3) samba's passdb pdbedit -L

Code:

root@homenas[~]# pdbedit -L
smbuser:1000:smbuser

If you don't see it here, run command midclt call smb.synchronize_passdb.

Last command is a backgrounded job and returns a job id. You can check on its status with midclt call core.get_jobs '[["id", "=", <job id>]]'

If you have to run any of the above commands, send me a debug through a private message and I'll check logs to see whether there's a bug to fix. This is something that should just work (without having to intervene through CLI).

 

[johnswenson1]

Hi anodos,
I finally got some time to check this, the user (servershare) was not found by either of the first two techniques. When attempting to run:
midclt call service.restart user
I get a python traceback ending in NotImplementedError. A couple lines above that is
await service_object.stop()

I'm not sure how I get a file of the shell output.

Thanks,

John S.

 

[anodos]

Hi anodos,
I finally got some time to check this, the user (servershare) was not found by either of the first two techniques. When attempting to run:
midclt call service.restart user
I get a python traceback ending in NotImplementedError. A couple lines above that is
await service_object.stop()

I'm not sure how I get a file of the shell output.

Thanks,

John S.

Sorry. Typo. midclt call service.reload user.

 

[johnswenson1]

Sorry. Typo. midclt call service.reload user.

I tried this and it came back with true and now the name (servershare) shows up in master.passwd and passwd as well as pdbedit -L .

I tried mapping to the windows machine again with:
\\truenas.local\Share1

I also tried using the IP address for the server, that didn't work either.

A popup is already specifying servershare, I typed in the password I entered in the GUI for servershare and it comes back with incorrect network password.

I'm not sure what is going on at this point.

Thanks,

John S.

 

[johnswenson1]

I had a couple months of lots of other stuff to do but I am back now working on this server. I'm not sure if this is the issue, I did a
smbd -b

and get :
SMB_PASSWD_FILE: /var/db/system/samba4/private/smbpasswd

I went to this directory, there is no smbpasswd file. There IS a passdb.tdb file.
I used the gui to change the password to the account and the passdb.tdb file did change to a timestamp of when I made the password change.

Tried to map a drive from windows, did not work.

I did a
cp passdb.tdb smbpasswd

so both files existed. It still did not connect.

I restarted the server, the copied file was still there, tried to connect again, still did not work.

I did some looking in the log files and the windows machine IS talking to the server but when smbd cannot find the account name. The log file does does not say exactly what file it is looking at, just that it tried to look up the user and could not find the user.

So I still do not know what is going on.

John S.

 

[AndroGen]

Hi John S.,

my learning related to this / similar topic:
All objects, which should participate in the SMB - have to be created as SMB right from the moment uno.
If SMB is enabled "later" - there is all sort of funky behavior.
I had very similar issues, also including the authentication issues, where session user was jumping between different ones (my win 10 has multiple users I have to use accessing different resources).
If by any chance you have created one or another resource (e.g. Data set, users, shares) and activated SMB "afterwards" (or you are not 150% sure)...
It might be easier to recreate all that - this is my experience.
After "starting from scratch" and recreating all objects as SMB enabled at the moment of creation - my problems are gone.
Maybe it is not how it should work out of the box, and maybe it is not your exact case, but this is my experience.

Regards, Andrey

 

[johnswenson1]

It WORKS!!

The big thing was to have the dataset owned by the account I was using as the credentials from the Win10 machines. Once I did that, it all worked fine.

I did enable ACLs on the dataset when I created it, the share took it fine and windows talks to it.

I had several machines connected and transferring videos, playing them back etc, this little server barely got above 10% CPU usage, not bad.

Now on to figuring out snapshots, backups etc.

Thanks to all the responded.

John S.