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
I've been in and out, up and down with this problem for months now without a solution.
My FreeNAS Dashboard (192.168.90.14) is accessible from Windows desktop, as is the Plex Server (192.168.90.170) running on the FreeNAS Server, but I'm unable to map the Freenas SMB Shares to Windows File Manager. Windows keeps rejected the mapping attempt saying "Wrong network password", although it was accessible prior to whatever changes (a) caused the problem.
Was the block caused by the dreaded Windows 10 Build 1909? Or (b) did I make some changes to the SMB Shares configuration - such as recursively applying changed settings?
If so, how do I fix this without losing the data on my shared FreeNAS volumes?
I'd really appreciate someone helping a FreeNAS novice out of one very frustrating pickle.
 
Joined
Jan 7, 2015
Messages
1,150
I think this should be pretty easy to fix. I wouldnt worry so much about losing anything, but you might want to do a recursive snapshot of all your pools before tinkering with all of this, just in case. Save a fresh FN config too.

What user are you using to connect? What user owns the data in FN? What group does this user belong to? Are you certain the password is correct?

If its me, I would make a user that matches your Windows user in Freenas, then add your new matching user to all the pertinent auxillary groups media, plex, ftp, etc.. etc.. Then when you are trying to map use these new credentials that match your windows user, aleviating permission/password issues.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
I've been in and out, up and down with this problem for months now without a solution.
OLD INFORMATION SUPERCEDED AS BELOW
Further to my earlier posts, I'm not out of trouble yet but I'm starting to understand the problem/s. I've isolated the FreeNAS access issue to my having unknowingly screwed up permissions on my FreeNAS Shares.
In my attempt to learn, I've been tooling around with Midnight Commander and found that I can change permissions on a 1x1 Folder/File basis to regain access but, with thousands of directories and files, this is not practical. Also, because I don't fully understand the appropriate permission combinations and permutations for Users, Groups and Others, I'm no closer to fixing the overall problem: regaining full, permanent and technically appropriate access to my FreeNAS Share folders and files.
I've been able to connect to my Shares via another PC running Zorin Ubuntu. That has given me an easier way than MC to bulk edit the permissions, but the result is not permanent. When I log back in to the edited folder or files on the FreeNAS Server, the permissions seem to have reverted and, to add fuel to the fire, I found that my Media Monkey Media Server is unable to upload new media files unless I juggle permissions from the Zorin system, but the temporary changes seem to revert inconsistently when I check them on FreeNAS (which is what Media Monkey looks at).
So, I think I've boiled my problem down to needing to know how to do the bulk Folder/File Permission changes inside the FreeNAS environment.
I've tried this before but, possibly because I previously screwed up my Permissions due to wrong (uninformed) use of the Recursive function, it wasn't successful. On top of this, using MC on the FreeNAS UI doesn't seem to work properly, but in any case, I suspect MC is not the right tool to perform a bulk permissions edit.
Given all this, I think I need assistance with the right FreeNAS Shell command syntax to run at individual Share level that will trickle down though the folders and resident files to change permissions for all artifacts.
My original intention was to have one Share setup as Private, requiring different User/Group permission access and another as Public, but that is probably overkill as I'm the only user that accesses the files anyway and indivual sign on at the Windows PC is probably sufficient protection. Besides, it involves photos, music files and mostly non-confidential documents, so security is not a major problem.
I hope somebody can make sense of all this and help me fix my problem.
Thanks in advance.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
@geoffwhere One or more shell commands could well fix your problem, but more info is needed.

1. Which version of FreeNAS are you using?
2. Was each dataset shared created with a "windows" share type?
3. Is the path of each of your SMB shares of the from /mnt/<pool name>/<dataset name> and not simply /mnt/<pool name> ?
(path is shown in FreeNAS webui for each share)
4. When accessing each SMB share from Zorin, is that via the file manager's (nautilus?) network browser ( smb:// .... )?
5. For one/all of the shared datasets) post the output of this shell command: "getfactl /mnt/<pool name >/< datset name>

( Here's an example for a dataset with owner/group chris:


Code:
root@freenas[~]# getfacl /mnt/Npool/wdata   
# file: /mnt/Npool/wdata
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow
root@freenas[~]#


)
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
@geoffwhere One or more shell commands could well fix your problem, but more info is needed.

1. Which version of FreeNAS are you using?
2. Was each dataset shared created with a "windows" share type?
3. Is the path of each of your SMB shares of the from /mnt/<pool name>/<dataset name> and not simply /mnt/<pool name> ?
(path is shown in FreeNAS webui for each share)
4. When accessing each SMB share from Zorin, is that via the file manager's (nautilus?) network browser ( smb:// .... )?
5. For one/all of the shared datasets) post the output of this shell command: "getfactl /mnt/<pool name >/< datset name>

( Here's an example for a dataset with owner/group chris:


Code:
root@freenas[~]# getfacl /mnt/Npool/wdata  
# file: /mnt/Npool/wdata
# owner: chris
# group: chris
owner@:rwxpDdaARWcCos:fd-----:allow​
group@:rwxpDdaARWcCos:fd-----:allow everyone@:--------------:fd-----:allow root@freenas[~]#


)
WOW! Thanks for the immediate response, my answers follow:
  1. FreeNAS-11.3-U5
  2. Yes, they're all Windows Shares (SMB)
  3. /mnt/Primary_Data/Geoff and /mnt/Primary_Data/Public (I'd prefer to keep them separate as is, but I'm not sure about how to assign or reassign User & Group and whether I need to, as that was done through FreeNAS when I originally created them and I've since fooled around with those properties).
  4. I've been using Zorin 'Files' to access FreeNAS Server through the LAN, having established 'Primary_Data' as an 'Other Location'.
  5. root@freenas[~]# get facl /mnt/Primary_Data/Public; /mnt/Primary_Data/Geoff:
# owner: root
# group: wheel
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--a-R-c--s:-------:allow
everyone@:rwxp--a-R-c--s:-------:allow
I hope this is what's needed for a clean fix.
Regards,
Geoff
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
@geoffwhere Next questions. Did you create a "geoff" account in FreeNAS to use as the credentials when connecting to the SMB share in Windows? Don't know if you were using a "guest account" in windows 10 for your public share, but that can be done in another way.

This is fixable via the FreeNAS webui using the ACL editor.
 
Last edited:

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
Yes, created a geoff user account which was intended to be used for the /mnt/Primary_Data/Geoff Share, as well as another user account for the Public Share.
I had been signing in to those Shares from Windows by mapping the Shares as Windows disk drives, but that all fell by the wayside after I screwed the permissions.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
OK, start by taking a snapshot of both your "Geoff" and "Public" datasets so you can rollback to your starting state if things go wrong.

1. Step one, remove wrong ACL:

For the /mnt/Primary_Data/Geoff use the ACL editor to strip the current ACL via the webui. Go to Storage > Pool and select three dots on the right of named dataset line and choose "edit acl". On the "Storage/Pool/Edit ACL" screen top lefthand side select "geoff" for both user and group and select both the "apply user" & the "apply group" tickboxes. Also select "Strip ACLs" at bottom left of screen, confirm this choice, and then press SAVE.

2. Step two, apply correct default SMB ACL:

For the /mnt/Primary_Data/Geoff use the ACL editor again. Select "RESTRICTED" for the default ACL options. After the screen refreshes, change the group@ settings on the righthand side from "modify" to "full control". Then select to apply permissions recursively and apply permissions to child datasets, confirm this, and then save.

3. Step Three, use getfacl to check dataset, file & folder ACLs

Use getfacl in the shell to check ACL, it should be as per my previous output, but with "geoff" as owner/group.

4. Test access from windows by mapping share with Geoff credentials.

Personally I wouldn't bother with a public share in your case, just set access for both datasets in the same way.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
start by taking a snapshot of both your "Geoff" and "Public" datasets
Again, thanks for your thorough response. As a complete novice in this environment I'm very appreciative of your easy to follow instructions. One thing I'd like to make sure I understand: in taking the 2 dataset snapshots should I select the Recursive option? Or does this only apply if there was another seperate dataset within each of my 2 sets (as opposed to folders and files inside those sets)?
Looking at the snapshot process another way, by taking 2 separate snapshots of the datasets (Geoff & Public), would FreeNAS automatically merge a recovery of those snapshots without disrupting the other sets within the parent 'Primary_Data' set?
Or, should I take a snapshot of 'Primary_Data' and then select the Recursive option, so as to include Geoff & Public (and the other datasets that are in Primary_Data, such as Plex Server, MMPC backup, et al)?
Maybe a dumb question but your answer will help me get my head around the internal workings.
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
@geoffwhere About snapshots, the recursive option only applies when there are datasets within datasets. Yes to your 2nd question. I tend to work with snapshots of individual datasets rahter than snapshots of an entire pool, so in this case create snapshots of Geoff & Public to recover form. These snapshots can be deleted once you've fixed the ACLs.
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
OK, start by taking a snapshot of both your "Geoff" and "Public" datasets so you can rollback to your starting state if things go wrong.
The Manual is not very clear on setting up a 'one off' snapshot. I hope this is a correct interpretation (ditto for Public):
1611456383780.png
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
The Manual is not very clear on setting up a 'one off' snapshot. I hope this is a correct interpretation (ditto for Public):
View attachment 44596
Well, that didn't work so I'm still in the dark about how to run a one-off snapshot. The above snapshot (and its twin for the Public dataset are sitting there with status 'Pending'.
1611460962191.png
 
Last edited:

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
You are taking a snapshot as a precuationary measure only in this case, a "point in time copy" you can rollback to if something goes wrong when you change the dataset ACL, etc. It's a "one off" manual snapshot which you can create as per example below. It's not done via a periodic task and if the ACL change is successful you can immediately delete this manual snapshot. ( If you have a schedule of periodic snapshots already set up on the same dataset, do these ACL changes in the interval between the timed snapshots)

Go to "Storage/Pool" and select the three dots to right of line with the named dataset and then select "create snapshot". For example:

snap1.jpg


snap2.jpg
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
strip the current ACL via the webui.
I assume that, when you say "select "geoff" for both user and group and select both the "apply user" & the "apply group" tickboxes. Also select "Strip ACLs", you're saying strip the current user/group. Could this mean the user/group currently attached to the dataset?
Problem: In my futile attempts over time to get this working I've created multiple Users & Groups and now I don't know which combination is assigned to each dataset.
These are the current User/Group sets (assigned across both Geoff & Public datasets):
USERS:
sawit (1000); administ (1001); gwhitele (1002); plexuser (1003); geoff (1004), root (0)
GROUPS: Public (1000) - members: sawit; Admin (1001) - members: administ; geoff (1002) - members: geoff, gwhitele; sawit (1003) - members: sawit; plexuser (1004) - members: plexuser; wheel (0) - members: root
Is this a process of eliminating what's there (or what could be there, given the above vagueries), eliminating it and starting from scratch by assigning a new user/group to the ACLS?
If so, would your Step 2 above (apply correct default SMB ACL) be modified to assign what would remain of the users/groups listed above (e.g. user: geoff (1004) and group), after after going through step 1 for all the possible user/group combinations, and culling the unwanted ones?
Or do I just ignore the possible mix of various user/group assignments and just strip the ACL and select "geoff" for both user and group (as per Step1)?
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Q1. THE "strip ACL" action alone does not remove/change the current owner/group. You could opt to apply the owner/group you want in my step2.

Deleting any user/group you've already added and is redundant is your choice, but removing unwanted entries would help to avoid later confusion. But do this after fixing the ACL first.

From your description you want at least a user/group for "geoff" in order to access a share of Primary_Data/Geoff using these credentials. You already have a user & group with id 1002 which you could use and then later remove the unwanted user with id 1004.

If you are using, or plan, to use plex then that may need additional changes. Post the output of these shell commands:

zfs list
ls -l /mnt/Primary_Data
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
Check Primary_Data/Geoff was created as share type SMB by looking at the dataset's acl mode using "zfs get aclmode Primary_Data/Geoff" in the shell. It should be "restricted".

Also, if you leave the OWNER/GROUP as ROOT/WHEEL, is "Strip ACL" still disabled?
 

geoffwhere

Contributor
Joined
Apr 23, 2020
Messages
105
zfs get aclmode Primary_Data/Geoff
NAME PROPERTY VALUE SOURCE
Primary_Data/Geoff aclmode passthrough local

Affirmative, with root/wheel, 'Strip ACL' not available
 

KrisBee

Wizard
Joined
Mar 20, 2017
Messages
1,288
OK, looks like when you created this ( and other? ) datasets you did not notice you needed to set the dataset share type to SMB, or at some later date changed that to GENERIC ( see for example: https://youtu.be/mCfX4sqDmzs at around 1.06 min). I need to check something, but will be off-line for a couple of hours.
 
Top