I’ve just returned to Rockstor after many years and made it smoothly through the install process for the current stable release (on a Dell T20, SSD boot disk with 2 pooled HDDs), feeling very good…and then hit Samba access issues in Windows 10 where I’m now entirely out of ideas and hoping for some help after hours of trial and (mostly) error.
I’m probably overlooking something insanely simple, but I’ve got absolutely no idea what it is. If I wasn’t so frustrated, it would be more amusing than apt that every Samba Windows credentials example in the documentation shows an “Access Denied” error message below it.
Neither the appliance or the shares are visible under Network (the appliance showed up after installing the ‘Web Service Discovery for Windows Networks’ Rockon, but didn’t seem to fix any access issues. Connection attempts result in similar error messages to other approaches.).
Trying to connect using all documented Windows approaches results in errors rejecting access regardless of using the IP or hostname. I’ve tried credentials for both the Share owner (no web UI access) and an admin account (with web UI access).
Entering only in login credentials I get “The specified network password is not correct”
Changing the username to include the workgroup like ‘WORKGROUP\myusername’ then denies access due to ‘invalid username’
I’m copy/pasting directly from a pw manager and have updated the user passwords the same way to double check they match
The Samba shares and exports appear to be set up properly and I’ve toggled every Windows 10 Pro (Version 22H2) option I can either think of or google.
The service is turned on
The samba service has a matching workgroup name to the Windows device
Group is set to ‘users’ which matches both admin and non-admin users created
A user has been created and identified as the owner of the Share
I’ve added Read/Write/Execute permissions on the Share for both owner and group
I’ve checked the smb.conf file to confirm it matched other examples posted here
The samba service has been turned on/off several times after changes
I’ve deleted and re-added exports
I’ve changed Share owners between admin and non-admin users
I’ve tried all kinds of combinations of export options with seemingly no effect. Currently I’ve got one admin user, browseable=Y, guest=N, read only=N.
I’ve turned on Windows features for SMB 1.0 and confirmed that SMBDirect was on
‘File & Printer Sharing Over SMBDirect’ has been enabled for windows firewall passthrough, along with ‘HomeGroup’
I’ve tried to add new Windows credentials for the login to Credential Manager
Confirming, yes, I read through the docs there. To get more familiar with the system I was basically using the table of contents as a guide and working through initial setup items one by one.
I’ve got “Uses openSUSE Leap Linux: 5.14.21-150400.24.46-default” as the version installed.
I’m not sure if it’s a related symptom, cause, or nothing at all but I’ve also had a few failed Rockon installs for Jellyfin and can’t access the UI for sabnzbd now (“Site can’t be reached” error) when I initially could.
And the Rockstor version is on top of that (in this case 4.6.1-0). In the next release the openSUSE flavor (Leap, Tumbleweed) version will be explicitly included in that line, instead of the hovering tooltip.
Not sure that it will give us any more insight, but at the command line, can you execute:
net rpc share list -U <enter User name that should have access to a given samba share>
it should ask for the password of that User ID you in the -U option. If that goes through without error, it should show which samba shares one should have access to. May be this can help narrow down what’s going in w.r.t. access.
You should definitely not be required to turn on the SMB 1.0 features on Windows. Not that it’s any consolation for you situation but in conjunction with the wsdd Rock-on I both get visibility on the network and also don’t have challenges logging in.
I created a sample share (owner/group: root/root) and subsequently a samba export, which looks like this:
I do have Norton antivirus running, but no firewall beyond what Windows has. My laptop is connecting over wifi to a Ubiquiti AP and router while Rockstor is hardwired to a switch on the same network.
The only other potentially relevant detail I can think of is that when I did the recent install, I just wiped the boot drive and then re-imported the existing Rockstor pool I had for storage, but that would have been created under one of the original CentOS builds. This Video share was created previously, but in the last few days I’d also tried to create exports with newly created shares and exports as well with the same outcomes.
You can test the configuration file’s consistency by running:
If it’s not loading the samba configuration file, then it probably uses some built-in standards for some of the parameters and not for others … maybe the output will tell you a key items that’s missing or entered incorrectly, etc.
Here’s a non-exhaustive tutorial on using testparm:
Maybe a slight brain cramp on my part, I was just using the system shell to run commands and it didn’t occur to me that they weren’t being run with root permissions. Re-running the “net rpc share list -U”, it’s still and error, but a different one:
mhm. I still have a NetBIOS name and some Apple related settings in the Rockstor Global Custom section, and am also forcing a minimum Samba level of smb2, but the shares look pretty much the same on mine as on yours …
It is curious that even with the “internal” 'net rpc share list` call any authentication seems to fail …
and the various samba log files don’t show anything unusual (sorry, that’s a very generic question, since I’m not defining what unusual really means)?
Can you log in via either the system shell on the WebUI with any of those users you’ve created and are using for samba (I think I remember something about lack of case-sensitivity on the windows side?
Could you, for fun also create a user that’s all lowercase, and not a mixed case, unless you’ve already proven that theory wrong.
It totally hadn’t occurred to me that case sensitivity might be involved but, by chance, one of the users I created and tested with was all lower case. I just checked, and it can log in on the system shell - it wasn’t set up for WebUI access whereas the other username is. The mixed case username can log in to both the WebUI and the shell.
I don’t exactly know how the smb user and Linux user are synchronized with their passwords in Rockstor, but may be they’re out of sync (for some reason).
@Flox, @phillxnet any idea here? I believe options like unix password sync=yes and passwd program or passwd chat were ever set in the past, so not sure why other users have not reported on this issue (and I don’t have it on the current stable release either).
Not that it should be common practice, but can you connect to the smb share using the root user?
The NT_LOGON_FAILURE you see with net rpc may be a red herring as you may need to specify the server. For instance it works for me when doing the following either from the Samba server itself, or a separate client:
On the samba server:
buildvm155:~ # net rpc share list -U testuser1 -S buildvm155
Password for [WORKGROUP\testuser1]:
On a separate client:
$ net rpc share list -U testuser1 -S buildvm155
Password for [WORKGROUP\testuser1]:
You can use the IP address here instead of the hostname.
@vancouverish , I know you detailed (thank you!) how you tested a lot of combinations, but to verify: does it still not work if you enable guest access for that Samba export?
Additionally, to make sure there isn’t a misuderstanding, what is the current Access control for that share? Mine is as follows, for instance:
To make sure everything is OK with your Pools/Shares, would you mind verifying that there is no reported issue on the Pools, Disks, and Shares pages? Screenshots as you please if that’s alright with you.
ok, might very well be. Using PuTTY (not the system shell) on my physical system (and additionally on a vm instance) the server was not required for the logon to be successful … but it’s probably a good idea to specify it, just to make sure it’s trying to authenticate against the “correct” server…