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

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
Thanks again for your perserverance, much obliged.
I'm pretty sure I originally set it up as SMB but subsequent fooling around may have undone that, to be determined.
Will look at the video link, thanks. Bed time here now (what is your time zone?)
Hope we can get onto this tomorrow - I have some other tasks in my morning until early afternoon.
Stay safe, keep well.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
UK here, you're well ahead of me, but I bet it's not snowing in your part of the world. Leave fix until to tomorrow. I mis-read your answer to this question in my first post: "2. Was each dataset shared created with a "windows" share type?" A saying "Yes, they're all Windows Shares (SMB)" is not the same thing. In case your wondering, I has been offering a solution which would enable you to learn how to sort this kind of thing out, rather than simply giving you a set of commands to execute at the FreeNAS shell.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
@geoffwhere Hopefully you'll see this first thing tomorrow.

Clearly for anyone new to FreeNAS who as either never used a NAS appliance before, or used a simpler product like QNAP or Synology, there's a learning curve with pitfalls.

One common pitfall is to create a pool, say named "Primary_Data", and then create a SMB share based on the path "/mnt/Primary_Data". Not only does this mean not making any real use of the dataset concept, but it leads to problems in later versions of FreeNAS, such as upgrading from FreeNAS 11.3-U5 to TrueNAS CORE where this is prevented/prohibited. You avoided that one.

The next common pitfall is to create datasets without noticing you need to decide the share type "GENERIC" or "SMB" at the time of its creation. This is not the same thing as later picking the dataset when adding a SMB share.

The share type choice determines how both the "aclmode" and "casesensitivity" dataset properties are set. (You can see the values of those properties after dataset creation via the webui by selecting the dataset "edit options" on the Storage/Pool page. At the FreeNAS shell they can be displayed via the command "zfs get all /mnt/<pool name>/<datsaset name>").

SMB shares have aclmode "restricted" and casesensitivity "insensitive". Additionally, when a dataset of share type SMB is created it's given a default ACL which can then be amended via the ACL editor within FreeNAS.

GENERIC shares have aclmode "passthrough" and casesensitivty "sensitive", but they are not given a default ACL, only standrd unix/linux type permissions. Hence "strip ACL" is disabled on the FreeNAS ACL editor web page.

Currently, your "Primary_Data/Geoff" dataset looks to be configured for use as a GENERIC share. As you're only accessing shared data via Windows your only concern is to correctly configure SMB shares and ACLs on your datasets. So, how do your turn a "GENERIC share type" dataset in to a "SMB share type" dataset?

Firstly, go to Storage/Pool and in the same way you can choose to make a manual snapshot, choose "edit options" for the dataset. Then select ADVANCED MODE and then change the aclmode to RESTRICTED and finally save.

Secondly, carry on from my step 2 above.

There is one small fly in the ointment, your dataset will be left with a casesensitivity of "sensitive". That is not correct, but unfortunately this property is immutable. In most cases, it shouldn't matter.

These FreeNAS vids are still valid and worth a look:


This FreeNAS blog entry will be relevant if you're using PLEX:
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
UK here, you're well ahead of me, but I bet it's not snowing in your part of the world
Definitely not, but it is getting towards the end of the wet season, so plenty of rain and cloying humidity is the order of most days. At least the nights are cooler but not for much longer.
In case your wondering, I has been offering a solution which would enable you to learn how to sort this kind of thing out, rather than simply giving you a set of commands to execute at the FreeNAS shell
And for that I'll be eternally grateful. Many 'in the know' people make assumptions about a novice's understanding of their explanation context and dependencies. As illustrated by some of your previous guidance, I've been fortunate in having you come back with a response that elevates my understanding, rather than just performing some rote command that has no context to improve my understanding of what might be going on under the covers. Again, I thank you for your patience and courtesy.
The next common pitfall is to create datasets without noticing you need to decide the share type "GENERIC" or "SMB" at the time of its creation. This is not the same thing as later picking the dataset when adding a SMB share.
That's interesting and adds to the complexity that I have no concept of. Hopefully after this is all done and dusted, my horizons will have widened significantly. Perhaps from my novice perspective, what baffles me is that, while I can see some of the folders and files (those that I was able to get through by doing the long-hand permissions edit via MC), I'm able to access those from Windows File Manager (see screenshot below), but it's far from complete and not very proper.
I'm looking forward to understanding how that all works between SMB, GENERIC, etc.
Anyway, I'll plow on now with your latest guide.
Thanks again and remember, don't eat the yellow snow. :tongue:
1611563407826.png
1611563442994.png

1611563478759.png
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
[QUOTE="KrisBee, post: 626919, member: 72254"]
GENERIC shares have aclmode "passthrough" and casesensitivty "sensitive", but they are not given a default ACL, only standrd unix/linux type permissions. Hence "strip ACL" is disabled on the FreeNAS ACL editor web page.
[/QUOTE]

I notice that, after changing to RESTRICTED mode and group@ Full Control, the Strip ACLs option is now enabled. So, should I also complete Step 1, including changing User/Group to geoff/geoff, before completing Step 2 of your earlier guide?
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Starting from my step2 should be OK.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
Secondly, carry on from my step 2 above.
The User/Group is still appearing as root/wheel
root@freenas[~]# getfacl /mnt/Primary_Data/Public
# file: /mnt/Primary_Data/Public
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow
root@freenas[~]# getfacl /mnt/Primary_Data/Geoff
# file: /mnt/Primary_Data/Geoff
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow
Mapping to these Shares, Windows File Manager rejects - not authorised. Contact your network administrator
1611570282918.png
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Use the FreeNAS ACL editor to apply the correct owner/group to the datasets you're sharing. From my instructions: "On the "Storage/Pool/Edit ACL" screen top lefthand side select for example "geoff" for both user and group and select both the "apply user" & the "apply group" tickboxes and then SAVE". Just select your user/group from the drop down lists before ticking the apply boxes.

If you look at those ixsystem videos I listed above, you'll see an alternative way of doing this where the owner/group is left as root/wheel and a specific ACL is added to the dataset to allow full access for a given user.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
If you look at those ixsystem videos I listed above, you'll see an alternative way of doing this where the owner/group is left as root/wheel and a specific ACL is added to the dataset to allow full access for a given user.
Tried this approach and the other way of assigning geoff/geoff to user/group but keep getting knocked back by Windows File Manager, which insists I either don't have permission (contact your administrator) or I'm using the wrong network password. In some cases it asks me to login with another (now redundant) user name and, even if I choose 'login with other credentials', Windows still says I'm using the wrong password. I've deliberately edited the geoff user to reconfirm the password multiple times, but to no avail.
So many combinations of inter-related variables between seperate settings parameters for the dataset, users, groups and ACL, I don't know whether I'm Arthur or Martha in trying to find a workable combination.
Is it getting screwed up by having the same user/group (geoff/geoff) for both Datasets (Geoff, Public)?
If I delete the redundant (or perhaps all) Users and Group Account settings will that compromise the data files in the datasets? If not, would starting from scratch with the users, groups and ACL settings maybe unjumble things?
Here's the current getfacl parameters:


root@freenas[~]# getfacl /mnt/Primary_Data/Public
# file: /mnt/Primary_Data/Public
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
user:geoff:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

root@freenas[~]# getfacl /mnt/Primary_Data/Geoff
# file: /mnt/Primary_Data/Geoff
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
user:geoff:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Assuming you have files and folders inside /mnt/Primary_Data/Geoff for example, did you apply the changes recursively in the ACL editor? The getfacl output for /mnt/Primary_Data/Geoff looks correct, but what's the output of getfacl for a file or folder within the dataset, eg. "getfacl /mnt/Primary_Data/Geoff/<somefile>" ?

Let's check that the SMB account for "geoff" exists in FreeNAS. What's the output of this command in the FreeNAS shell: "pdbedit -L" ?

When testing changes in FreeNAS that can alter SMB access, like changing ACLs, close file explorer before logging out of Windows and then login to Windows again. This will ensure any SMB connections are closed and the windows session credentials are cleared. The output of the command "smbstatus" in the FreeNAS shell will display information about SMB connections. I'd also delete any existing Windows drive mappings to FreeNAS while testing and access shares without mapping the drive ( see for example: https://www.ixsystems.com/blog/windows-smb-shares-on-freenas/ )

Are you still using Windows 10 build 1909? I probably should have asked before, but are you logging into Windows with a "Microsoft Account" or a "local account"? When creating user accounts in FreeNAS did you select the "Microsoft Account" tickbok? If it's a local Windows account, when you login to Windows do you use the exact username and password combination taht you have given to your "geoff" account in FreeNAS?
 
Last edited:

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
Assuming you have files and folders inside /mnt/Primary_Data/Geoff for example, did you apply the changes recursively in the ACL editor
Yes I did. And went back over it several times to make sure I had all the settings right.
Despite my my limited knowledge on this subject, could we be at crossed purposes regarding the allocation of user/group geoff/geoff in two separate shares: the /Primary_Data/Geoff and /Primary_Data/Public shares?
Is it a show stopper if we allocate geoff/geoff to both ACLs? For example, if user geoff Home Directory is /Primary_Data/Geoff, does that mean user geoff can't traverse across to the /Primary_Data/Public directory? I tried to make the Home Directory one level higher, but that was rejected because the /Primary_Data level is not permissable.

what's the output of getfacl for a file or folder within the dataset, eg. "getfacl /mnt/Primary_Data/Geoff/<somefile>" ?
root@freenas[~]# getfacl /mnt/Primary_Data/Geoff/Gridsense/Financials.xls
getfacl: /mnt/Primary_Data/Geoff/Gridsense/Financials.xls: stat() failed: No such file or directory
root@freenas[~]# getfacl /mnt/Primary_Data/Geoff/Gridsense
getfacl: /mnt/Primary_Data/Geoff/Gridsense: stat() failed: No such file or directory
root@freenas[~]# getfacl /mnt/Primary_Data/Geoff
# file: /mnt/Primary_Data/Geoff
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow

What's the output of this command in the FreeNAS shell: "pdbedit -L" ?
root@freenas[~]# pdbedit -L
plexuser:1003:Plex User
administ:1001:Administrator
geoff:1004:Geoff W
sawit:1000:Sawit

When testing changes in FreeNAS that can alter SMB access, like changing ACLs, close file explorer before logging out of Windows and then login to Windows again. This will ensure any SMB connections are closed and the windows session credentials are cleared
Noted

output of the command "smbstatus"
root@freenas[~]# smbstatus
Samba version 4.10.18
PID Username Group Machine Protocol Version Encryption Signing Etc...
----------------------------------------------------------------------------------------------------------------------------------------
No locked files

Are you still using Windows 10 build 1909?
No, got out of that frying pan into the 20H2 fire which seems to have settled down somewhat (but still has the niggling annoyance of not keeping mapped drives after reboot).

When creating user accounts in FreeNAS did you select the "Microsoft Account" tickbok?
Yes.

Again, thanks for your perserverance and my humble apologies for being such a luddite. I hope to get over this hump without any more pain.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
By using separate datasets you are able to group data and then set an ACL appropriate to each dataset. It doesn't matter if you end up sharing one or more datasets with the same ACL. If you did, then entering the correct credentials once should then give you access to one or more share. You'll have to be clearer about what you mean by user geoff Home Directory, whether you've set something in FreeNAS or windows. Have you set a home directory path for your "geoff" account in FreeNAS?

But what's happened to the dataset /mnt/Primary_Data/Geoff ? Your getfacl output above shows it's changed again? Things were looking as expected in #29 above, but not now! Could you also post the full getacl output for "getfacl /mnt/Primary_Data"

You didn't fully answer my final questions. AFAIK if you map a drive in Windows and expect to reconnect when you log back in, the account credentials in FreeNAS must exactly match those used for the Windows log in. I don't use Microsoft Accounts myself, did you also enter the email address of your Microsoft account when creating the "geoff" account in FreeNAS? Of course, you can choose to use another set of credentials to log into your FreeNAS shares from an active Windows session if you've created an additional local user account on FreeNAS, but if it's a different user to your Windows account a mapped drive set to reconnect at login will fail to connect unless you selected to remember the credentials.

Keep in mind the aim here is to ensure the "share type", owner/group & ACL of your FreeNAS datasets allows the correct access from Windows when the appropriate "network credentials" are used in Windows to connect to the share. Those credentials must match a user account added to FreeNAS and the ACL of the dataset must allow access for that user, or group the user is a member of. While testing use mapped drives but do not set to reconnect at logon. Afternatively, don't use mapped drives just click on the FREENAS under network you should then be prompted to enter the "network credentials".

We've all got to start somewhere, clearly this long distance interchange just proglongs getting this fixed. Being systematic is key here, be confident your FreeNAS setup is OK, then tackle any Windows glitches.

One possible glitch "remembered credentials" in Windows. You can use the windows credential manager to clear out any old and now invalid FreeNAS username/password combos.

I don't know how much data you've manged to get onto your NAS, the nuclear option of starting from scratch on FreeNAS is a last resort.
 
Last edited:

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
You'll have to be clearer about what you mean by user geoff Home Directory, whether you've set something in FreeNAS or windows. Have you set a home directory path for your "geoff" account in FreeNAS?
Yes I already had a Home Directory path for each of the 'Geoff' and 'Public' datasets. That setting was part of my original configuration and it worked fine, enabling me to segregate the two datasets (ostensibly for security reasons, which are not really critical but I thought it was a good idea at the time).
What's confusing me there is, if I use the same user/group on each of those datasets, does that matter to FreeNAS? In other words, does FreeNAS get its knickers twisted (and does Windows drive mapping care) if the same sign on applies to the separate datasets?
what's happened to the dataset /mnt/Primary_Data/Geoff ? Your getfacl output above shows it's changed again?
I somehow must have screwed that up. I find it daunting/annoying that, each time I open the Edit ACL dialogue, FreeNAS doesn't display the current settings, so if one's not careful a setting can change unintentionally without notice. I'll have another look at it and I probably should write down the settings as I change them so I can double check later if I re-edit.
root@freenas[~]# getfacl /mnt/Primary_Data/Geoff
# file: /mnt/Primary_Data/Geoff
# owner: geoff
# group: geoff
owner@: rwxp--aARWcCos:-------:allow
group@: rwxp--a-R-c--s:-------:allow
everyone@: ------a-R-c--s:-------:allow
are you logging into Windows with a "Microsoft Account" or a "local account"?
Sorry, missed that one. I use a Microsoft account.
AFAIK if you map a drive in Windows and expect to reconnect when you log back in, the account credentials in FreeNAS must exactly match those used for the Windows log in
Well, you might be onto something here. I've tried all the 'solutions' on the interweb, none of them work consistently. They range from Registry key changes to Services enablement and on and on the chatter goes to no avail.
ATM, that's the least of my worries but, after this other business is sorted I'll try changing the FreeNAS User passwords to match the Windows login.
BTW, I've edited another one of the FreeNAS users to have the same password as user: geoff and assigned one of those to Dataset Geoff and the other to dataset Public. This means that each user has their individual Home Directory within their respective dataset.
did you also enter the email address of your Microsoft account when creating the "geoff" account in FreeNAS?
Did have it set for 'geoff' and have checked same on other user 'gwhitele' whic is now attached to /Public dataset
Afternatively, don't use mapped drives just click on the FREENAS under network you should then be prompted to enter the "network credentials".
Does "network credentials" mean the Windows account login?
be confident your FreeNAS setup is OK, then tackle any Windows glitches
Agreed. As I said above, reconnecting at login is nice but not the current priority.
use the windows credential manager to clear out any old and now invalid FreeNAS username/password combos
Didn't know that, will do. Thanks. [a few minutes pass . . . ]
Just looked at Credential Manager - this might be the culprit. I noticed the stored passwords weren't apparently the same number of characters as the FreeNAS ACL, so I updated the credentials. About to restart and try it out.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
I'm stumped.
In one setup, the network device (/Geoff or /Public) shows on Windows Explorer when I click on the network device in the left hand directory panel. It begins with an error message about network access denied then shows the netwrk device icon but, if I double click on it or try to map to it, the same network access denied message happens, whether the FreeNAS User Account password is my WIndows account password or another separate password (i.e. not the Windows p/w).
Obviously there's a wrong setting somewhere, as I was previously able to get to the /mnt/Primary_Data /Geoff or /Public directories.
But I'm bamboozled by all the different FreeNAS Pools, users and ACL combinations that don't seem to follow any consistent pattern in terms of working or not working towards a particular configuration.
One thing I find makes it very difficult to understand is creating and managing closely inter-related/dependent artifacts such as datasets, SMB shares, users, passwords (whether they're supposed to be Microsoft account or FreeNAS passwords), etc are accessed from different sections of the FreeNAS UI with no dummy-friendly descriptions in the User documentation. The videos are a bit more helpful (I did use those on initial setup) but something changed - presumably because of an access failure after a Windows update that threw the whole Windows world into a black hole. That's when I started trying to fix FreeNAS access and screwed it up, but as per my rant just now, I'm drowning.
Starting from scratch, as you suggested is very much a last ditch approach - I'm afraid that, given the time that's passed since backups were possible and subsequent files (particularly photos of my new grandson) that may not be on the FreeNAS backups may get lost.
Perhaps if we can transport the FreeNAS Shares, via Shell or some other system level tool, to another disk (maybe an external USB HDD) that might be a good option. But I have no idea whether that's feasible.
I'm OK to proceed if you are, but I'm also conscious of over-extending my welcome.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
@geoffwhere Don't give up yet! As I said before it can be a steep learning curve.

You have unknowingly hit another possible ptifall in the way you decided to assign "/mnt/Primary_Data/Geoff" as the path of the "geoff" user's "Home Directory" when creating that account in FreeNAS. Not only is this unnecessary in your case, but causes ACL complications. It explains why the ACL on that dataset as shown in #29 (correct) changed to that in #33 (wrong). What happened was after first setting the correct ACL via the ACL editor any subsequent change to the "geoff" account where that same dataset is used as the account's "Home Directory" resets the ACL to effectively that of a GENERIC share type and undoes the ACL editor setting. So this really is causing you problems on the FreeNAS side.

You should set the "geofff" account "Home Directory" to its default of "/nonexistent"

Anyway, let's get over the hurdles. How about test driving this instruction set?

IN FREENAS

1. Create a new test user, filling in the following:

full name:
username:
password:

Keep the default of new primary group selected
Keep the default directory as "/nonexistent" and the default home directory permissions
Keep "disable password" as "no"
Set the shell to "nologin"
Do not select "Microsoft Account"
then SAVE

Make a note of the username and password used for later.


2. Create a new dataset, eg Primary_data/testset

Set the "Share Type" to "SMB"
Leave other setting as is, except you can turn set "Enable Atime" to "off"
then SAVE


3. Edit the ACL of the new dataset

Leave the owner/group as root/wheel
Click on "ADD ACL ITEM"
Set "who" to "User"
Select the name of your new test user from the dropdown list
Select "Permissions" to "Full Control"
then SAVE

(As this new dataset is empty there's no point in applying permission recursively)

4. Add a new windows share

Navigate to the name of the new dataset and select this as the share path.
(The dataset will be displayed with (ACL) appended to its name)
The share name will default to the new dataset name
Leave other settings as is
then SAVE


IN WINDOWS

5. Log into Windows with your usual name/password (not the name of new test user added in FreeNAS).

6. Check for old & now invalid credentials saved in the windows Credentials Manager. Remove any FreeNAS Credentials.

7. Disconnect from any existing FreeNAS drive mappings.

8. Log off Windows and then log in as per step 5 and check there are no FreeNAS credentials in the credential manager and no drive mappings appear in file explorer.

9. Use File explorer to map the new dataset to a windows drive letter.

On the Map Network Drive dialogue

select a drive letter of your choice
set Folder to share path in the format \\FREENAS\<sharename> (share name will be the new dataset name)
click to select both "Reconnect at sign-on" and "Connect using different credentials"
click Finish and you should be prompted to "Enter Network Credentials"

On the Enter Network Credentials dialogue enter the name and password of the new test user added to FreeNAS
and importantly click on the "remember my credentials" tickbox then click on OK.

If a second prompt appears asking to enter the password again for this user, do the same and select "remember my credentials"then click on OK.


You should now have access to your FreeNAS windows share. The mapped drive should be available after a Windows restart, or if you log off Windows and then log in again.
 
Last edited:

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
set the "geofff" account "Home Directory" to its default of "/nonexistent"
How do I do that? The Home Directory folder tree only has the folders that are in that dataset.
Is it a matter of deleting the /Geoff suffix and inserting the text "noexistent"? Wouldn't FreeNAS fall off its perch because that folder is not there?
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Just over type what's there. But do give the instruction set a run through first.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
On the Enter Network Credentials dialogue enter the name and password of the new test user added to FreeNAS and importantly click on the "remember my credentials" tickbox then click on OK.
If a second prompt appears asking to enter the password again for this user, do the same and select "remember my credentials"then click on OK.
2nd, 3rd and further attempts produce the "Specified network password is not correct" error! No mapping completed.
Is plex media server causing an obstacle? (While its a dataset on FreeNAS, it's on a different IP address).
1611751893070.png
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Which dataset are you trying share now? What's the output of the getfacl command for the dataset path (getfacl /mnt/Primary_Data/xxxx )? If you created a new user, are you sure your using the right name/pasword combo?
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
Which dataset are you trying share now?
What's the output of the getfacl command for the dataset path (getfacl /mnt/Primary_Data/xxxx )? If you created a new user, are you sure your using the right name/pasword combo?
Trying to share the test scrip dataset:
root@freenas[~]# getfacl /mnt/Primary_Data/testset
# file: /mnt/Primary_Data/testset
# owner: root
# group: wheel
owner@: rwxpDdaARWcCos: fd-----: allow
group@: rwxpDdaARWcCos: fd-----: allow
user:gwhy: rwxpDdaARWcCos: fd-----: allow
everyone@: -------------------: fd-----: allow
Yes, wrote the user/password down after creating the share and that's what I entered in the Windows Mapping tool.
 
Top