SMB Shares Inaccessible from Windows 10. What if I may have checked 'Apply Recursively'? Could that be the reason?

[KrisBee]

The above looks correct to me and your previous screenshot shows no pre-exisitng drive mappings and I assume all FreeNAS credentials have been removed before attempting to connect to your FreeNAS share. In Windows your folder path would be \\FREENAS\testset , the user for "network credentials" is "gwhy" and what ever password has been set for user "gwhy".

Looks like it's me who's missing something here. What's the output of these two commands in the shell?

pdbedit -L
testparm -s

Post results of each within code tags. ( ie bewteen )

Forgot to say, do you see "MORE CHOICES" on the enter network credentials dialogue? Do you still get an error if you select "more choices" first, and then enter your username/paswrod combo?

 

[geoffwhere]

What's the output of these two commands in the shell?
pdbedit -L
testparm -s

root@freenas[~]# pdbedit -L
plexuser:1003:Plex User
gwhy:1005:Geoff Why
administ:1001:Administrator
geoff:1004:Geoff W
gwhitele:1002:Geoff Whiteley
sawit:1000:Sawit
sawit:1000:Sawit
root@freenas[~]# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE
# Global parameters
[global]
aio max threads = 2
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
enable web service discovery = Yes
kernel change notify = No
load printers = No
logging = file
map to guest = Bad User
max log size = 51200
nsupdate command = /usr/local/bin/samba-nsupdate -g
server min protocol = NT1
server role = standalone server
server string = FreeNAS Server
username map = /usr/local/etc/smbusername.map
username map cache time = 60
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
allocation roundup size = 0
directory name cache size = 0
dos filemode = Yes
include = /usr/local/etc/smb4_share.conf
[Geoff]
aio write size = 0
comment = Confidential files
ea support = No
guest ok = Yes
guest only = Yes
mangled names = illegal
path = /mnt/Primary_Data/Geoff
read only = No
vfs objects = streams_xattr shadow_copy_zfs ixnas
nfs4:acedup = merge
nfs4:chown = true
[MMPC Backup]
aio write size = 0
ea support = No
mangled names = illegal
path = /mnt/Primary_Data/MMPC Backup
read only = No
vfs objects = streams_xattr shadow_copy_zfs ixnas
nfs4:acedup = merge
nfs4:chown = true
[Public]
aio write size = 0
comment = Shared files
ea support = No
guest ok = Yes
guest only = Yes
mangled names = illegal
path = /mnt/Primary_Data/Public
read only = No
vfs objects = streams_xattr shadow_copy_zfs ixnas
nfs4:acedup = merge
nfs4:chown = true
[plexshares]
aio write size = 0
ea support = No
guest ok = Yes
mangled names = illegal
path = /mnt/Primary_Data/Public/Media Files
read only = No
vfs objects = streams_xattr shadow_copy_zfs ixnas
nfs4:acedup = merge
nfs4:chown = true
[testset]
aio write size = 0
ea support = No
mangled names = illegal
path = /mnt/Primary_Data/testset
read only = No
vfs objects = streams_xattr shadow_copy_zfs ixnas
nfs4:acedup = merge
nfs4:chown = true

Post results of each within code tags. ( ie bewteen )

Don't understand.

do you see "MORE CHOICES" on the enter network credentials dialogue?

Yes.

Do you still get an error if you select "more choices" first, and then enter your username/paswrod combo?

Yes.

 

[KrisBee]

As a temporoary measure, disable all shares except the "testset" share in FreeNAS. Go to Sharing > Windows Shares and for each of those other shares select edit and uncheck the enable tickbox and save. For good measure can can stop and start the SMB services. Log out of Windows and then in again. Re-test connecting to "testset" share in Windows, but not by mapping a drive at the moment (click on FREENAS network icon etc. )

 

[geoffwhere]

Re-test connecting to "testset" share in Windows, but not by mapping a drive at the moment (click on FREENAS network icon etc. )

Bizarre. Still unable to access. I'm starting to lean towards some bad setting in Windows, but a few iterations ago without making any changes to Windows since, I was at least able to access both FREENAS\Geofff and \Public (I think that was before we changed the dataset permissions via Shell - might have that timing sequence wrong).
Here's the screenshot of this last iteration. I tried this twice, the second time after going back to the User and re-entering the password, just to be sure I had it right when trying to sign in from Windows Explorer.

 

[KrisBee]

Well, I thought just using one isolated test share would prove to work as there should be no confusion over credentials , no complication of Windows trying to establish a connection for a guest account, etc. Incidentally, guest access to shares is being phased out in Windows and is not recommended.

Have you got a solid connection between your PC and FreeNAS machine, i.e. wired and not wireless? Have you given your FreeNAS machine a static IP address rather than relying on DHCP, or at least reserved a lease for your FreeNAS machine? Pity you're not linux literate as you could test the SMB connection from linux and then be sure it's a Windows problem.

The screenshot shows your Windows machine sees the FreeNAS server and this ought to mean you've got file and printer sharing on for your private network. It's worth checking your Windows network settings and ensure you can "ping" your FreeNAS box from Windows.

Did you try just selecting the Network icon in the navigation pane and then typing "\\FREENAS\testset" into file explorer? Have tried substituting FREENAS for it's IP address, e.g \\192.168.10.10\testset?

I don't know if it will be a great help to turn on the logging of connections attempts in the Freenas ( assuming I remember how) and try to debug the problem that way. If it really is a windows problem then I'm not sure I can be of further assistance.

 

[geoffwhere]

Good morning,

Have you got a solid connection between your PC and FreeNAS machine, i.e. wired and not wireless? Have you given your FreeNAS machine a static IP address rather than relying on DHCP

Yes, wired (via an 8 port switch in this segment), although the connection to the gateway is via a WiFi extender. Not sure whether the IP traffic here goes throught the switch directlry to the othe devices on the switch or to the router then back to the switch then the devices. But that arrangement was not a problem earlier on when it was all working.

test the SMB connection from linux and then be sure it's a Windows problem.

How so? I'm willing to give it a try.

Windows machine sees the FreeNAS server and this ought to mean you've got file and printer sharing on for your private network. It's worth checking your Windows network settings and ensure you can "ping" your FreeNAS box from Windows.

Yes, and have been through the public/private Windows a network settings a hundred times, all seems good there (just checked again just to be sure).
Ping returns a response in 3-4 ms.

Did you try just selecting the Network icon in the navigation pane and then typing "\\FREENAS\testset" into file explorer? Have tried substituting FREENAS for it's IP address, e.g \\192.168.10.10\testset?

Have tried every combination possible, same result each one.

don't know if it will be a great help to turn on the logging of connections attempts in the Freenas

May be useful, happy to work towards finding out how.

Enjoy your day, thanks for your help.

 

[KrisBee]

I'm not sure changing the log levels in the SMB FreeNAS service alone will help without also getting into tcpdump/capture which is more technical and something I don't have time for at the moment.

One thing I should have suggested before is to check whether you can connect to a share within FreeNAS itself. The format of the commands to use in the FreeNAS shell is "smbclient //127.0.0.1/<sharename> -U <username>". Try if your test dataset and test user. After being prompted for a password, the response should be like this example where you can type "ls" to list share content ( none in your case) and then "quit" to return to the shell.

Code:

root@freenas-vm1[~]# smbclient //127.0.0.1/sharetest -U fred
Enter WORKGROUP\fred's password:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Jan 20 10:16:35 2021
  ..                                  D        0  Fri Jan 22 12:00:02 2021
  kid1                                A        2  Wed Nov  2 05:49:40 2016
  parent1                             A        2  Wed Nov  2 05:49:40 2016

                70072156 blocks of size 1024. 70072068 blocks available
smb: \> quit
root@freenas-vm1[~]#

If you want to return to your share of the "Primary_Data/Geoff" dataset, the output of the earlier "testparm" command shows you set both
guest ok = Yes & guest only = Yes, that makes no sense if you were then testing access by entering network credentials for the "geoff" account to access the share. Edit the share in FreeNAS click on "advanced" mode and unchecking those settings of "allow guest" and "only allow guest" if you want to re-try acccessing by user account from Windows to this share.

 

[geoffwhere]

check whether you can connect to a share within FreeNAS itself. The format of the commands to use in the FreeNAS shell is "smbclient //127.0.0.1/<sharename> -U <username>

root@freenas[~]# smbclient //127.0.0.1/Primary_Data/testset -U gwhy
Enter WORKGROUP\gwhy's password:
tree connect failed: NT_STATUS_BAD_NETWORK_NAME
root@freenas[~]#

Edit the share in FreeNAS click on "advanced" mode and unchecking those settings of "allow guest" and "only allow guest" if you want to re-try acccessing by user account from Windows to this share.

Unchecked guest settings, stopped/restarted SMB Service, refreshed Windows Explorer.
Tried connecting via Windows Explorer 'NETWORK' branch: User name or password incorrect (I deliberately re-entered the password and saved the FreeNASUser profile prior to attempting).
Then tried connecting via mapping to Windows Explorer 'This PC' branch: The Specified network password is not correct.
Then tried this 2nd approach but also checking 'Connect using different credentials, same error: The specified network password is not correct.
??

 

[KrisBee]

Command should be: smbclient //127.0.0.1/testset -U gwhy

 

[geoffwhere]

Command should be: smbclient //127.0.0.1/testset -U gwhy

root@freenas[~]# smbclient //127.0.0.1/testset -U gwhy
Enter WORKGROUP\gwhy's password:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Tue Jan 28 02:26:00 2020
.. D 0 Tue Jan 28 02:26:01 2020

2583639628 blocks of size 1024. 2583639540 blocks available
smb: \> quit
root@freenas[~]#

 

[KrisBee]

OK, its passed that test. Can you beg, borrow or steal a laptop and/or another Windows PC to try to connect to FreeNAS. You could at least then point the finger of blame on your Windows install/config. It may have worked once, but if you've made a lot of undocumented changes (anything to do with guest account access, etc, etc.) to windows and never created a backup of the working state to restore from, it looks as if you've simply dug yourself into a hole.

And what about using your zorin Ubuntu , surely that would confirm access to your FreeNAS SMB shares?

 

[geoffwhere]

beg, borrow or steal a laptop and/or another Windows PC to try to connect to FreeNAS

Great idea! There's one or two of those in this household, will give it a try later and post the result.

And what about using your zorin Ubuntu

Is there anything I need to do in particular to make a connection with that system? I've not had much time to play with that machine so I don't know much about the OS or utilities environments. Happyu to give that a try too.

On the balance of where we seem to be at, maybe (subject to checking out the above options) a viable path is to copy the data in /Primary_Data/Geoff & /Public (can this be moved to an external USB HDD (I've got enough USB storage to achieve that, just not enough knowledge of how to do it) and completely reinstall FreeNAS from scratch?

Maybe we park that idea until after I try the separate Windows machine access.

 

[KrisBee]

My adivce would be to try accessing your SMB shares from a different Windows devicet. But if you do so, disable all shares except for the test share your created in FreeNAS first.

 

[geoffwhere]

My adivce would be to try accessing your SMB shares from a different Windows devicet. But if you do so, disable all shares except for the test share your created in FreeNAS first.

Greetings Sir, It's been a weekend of family commitments, but I'm back in the saddle tomorrow morning (I think that will be late Sunday night your time).
Will test your suggested alternative Windows machine connect tomorrow a.m. and report findings.
In the meantime, what version of SMB does FreeNAS support and what might be the FreeNAS issues regarding MS pulling the plug on SMB V1, if any?
FWIW, I found the following write up on the MS SMB position and, although it's technically way beyond my level of comprehension, I thought it may be something worth considering. Or not.

Enable or Disable SMB1 File Sharing Protocol in Windows

How to Enable or Disable SMB1 File Sharing Protocol in Windows

www.tenforums.com

Enjoy your Sunday.

 

[KrisBee]

SMB v1 is insecure, don't use it even on a home network unless you have an old network printer, or something else, that refuses to work without it.

You should not tick the "Enable SMB1 Support" on the FreeNAS SMB services page, which I've just noticed you've must have done from the output of the "testparm" command above. But this should not effect connecting from Windows in normal circumstances as the output of "smbstatus" at the FreeNAS shell should show the connection is made using the secure version, SMB3_11.

 

[geoffwhere]

beg, borrow or steal a laptop and/or another Windows PC to try to connect to FreeNAS. You could at least then point the finger of blame on your Windows install/config

On a laptop running WIndows 10 Home (same as my desktop) I'm able to connect to datasets \Public, \Geoff & \testset. But only \testset is open to view files & folders. Both Geoff & Public show on Windows Explorer but I can't access those sets from the laptop.
On the desktop PC, although FREENAS appears in the 'Netwrok' list, I'm unable to connect to anty of those datasets. If I specifically map to \testset, it asks for the user (gwhy) and p/w (which worked on the laptop), but the desktop PC returns the message "specified network password is not correct".

 

[KrisBee]

And your conclusion is?

 

[geoffwhere]

And your conclusion is?

If only it was clear cut. It's obvious that there's inconsistent settings on all 3 platforms but it's beyond me to know where and what.
For example, that the laptop is able to 'see' the connection to all 3 datasets, it can only access one (testset). Why can it not access the other two? The laptop was also able to create a dummy .TXT file inside the testset dataset.
Also, that the desktop was previously able to 'see the Public and Geoff datasets but now cannot is also mysterious given that no changes have been made on the Windows side.
I've gone over the FreeNAS Shares settings multiple times and re-entered a password for those datasets yet, after clicking on the 'NETWORK' icon, Windows Explorer insists I'm using an incorrect network password or, if I try mapping to 'This PC', I get a different error message (incorrect user name or password).
To try to answer your question is probably best done by suggesting we start from scratch, subject to first harvesting the data files from Public and Geoff datasets.
What say you?

 

[KrisBee]

What say I?

1. Don't change any settings on your laptop right now. Windows 10 HOME may be installed on both your laptop and desktop, but are the builds and configurations & updates exactly in step?

2. Connections from your Windows 10 Home laptop to FreeNAS shares are as expected when using the testuser account credentials. In your case, the three folders seen in Windows correspond to the three FreeNAS SMB shares, but remember you've only configured the "testset" share to be accessed by the testuser account.

You should know enough now to make the other FreeNAS shares available by setting the correct dataset ACL in FreeNAS for the matching account you want to use when connecting in Windows. Then, you should be able to at least access your "Geoff" share using the "Geoff" account from your laptop. Don't mess with, or try connecting to, "Public" as a guest at the moment.

Remember if you map drives to shares and check the "reconnect on login" option then Windows will try to connect using the credentials (name/password) stored in the credentials manager. If you need to map more than one share in this way, Windows will try to use the same stored credentials for each share. For example, you can't expect to reconnect as a guest user to one share and as the "Geoff" user to another share at the same time.

3. Things may have worked on your desktop at one time in the past, but who knows what changes may have occurred. Your Windows desktop displays an error which when googled seems to have cropped on Windows 10 Home in various situations at different times. I've no idea why it happens. In some instances, the simple remedy of using the format "computername\username" rather than just "username" when entering the network credentials has made a difference (the computername here is that of the Window desktop). Others found this format worked: "<ip of server>/<username>", e.g. "192.168.10.20/fred" instead of just "fred" for the name, where the IP would be that of the FreeNAs box, substitute your own values.

How to proceed?

4. Sort out the access to your "Geoff" share from your laptop, to prove to yourself it works. Leave the "Public" share for now.

5. Try the suggestions in 3 above for accessing testset share from your desktop. Otherwise google on the Windows error message.

6. I doubt your problem with accessing your FreeNAS shares form your windows 10 home desktop will be fixed by starting from scratch on FreeNAS.

 

[geoffwhere]

What say I?

Courtesy update, I'm in sick bay running a 37.3c temp and headache so no activity today. Will report again 2moro