Fester's Very Basic One User/One Dataset Experimental Starter Share
Fester is still learning about shares and in particular share permissions.
As Fester learns more I will try to pass on what I have learned by adding to this section and creating additional guides for more “real world” share scenarios (if time permits).
This particular share will not be much use to most people, but it will get you going.
Don’t forget the official FreeNAS guide has lots of information on shares. But for now, this will be a very basic share on a FreeNAS system and is designed to get you started so you can experiment with shares.
Share Scenario
This share is designed for one user who wants to access the same share from different client machines.
The client machines will mostly be running Windows (or Mac OS X).
It will utilise one dataset and show you how to share it.
It is designed to get you started with shares so that you can experiment.
Share Creation and Configuration
User Creation
Click “Accounts” in the left column, then “Groups”.
Click the “Add” button. A new smaller window will pop up, where we can create a new Group.
Leave the “Group ID:” at its default value of 1001.
Now type in a name for the new group in the “Name” text box (because this is a starter share from which you can experiment, Fester used TestGroup).
Do not tick the “Permit Sudo:” or “Allow repeated GIDs:” tick boxes.
Now click the “Save” button.
If all goes well an entry should appear in the Account → Groups page. You should see something like this.
Now click “Accounts” in the left column, then “Users”.
Click the “Add” button. A new window will pop up, where we can create a new User.
Leave the “User ID:” at its default value of 1001.
Now type in a name for the new user in the “Username” text box (because this is a starter share from which you can experiment, Fester used TestUser).
Untick the “New Primary Group” tick box.
The “Primary Group” drop down selection box should now become active. The group we created earlier (i.e. TestGroup) should be available for selection.
Leave the “Home Directory” text box at the default /nonexistent.
Leave “Shell” at its default setting.
Type in a name for the new user (Fester chose Test User).
Create a password in the “Password” text box and confirm it by retyping it in the “Confirm Password” text box (because this is a starter share to experiment with Fester just used 12345. Make sure you use a stronger and less predictable password unless you want Planet Spaceball to steal all your air.)
Do not tick the “Disable password login:” you will lock yourself out of the share.
Leave the “Lock user:” and “Permit Sudo:” at their default settings of unticked.
Fester will be accessing this account from a windows machine so I tick the “Microsoft Account:” tick box.
Now click the “Save” button.
Dataset Creation
Now we need to create the dataset.
Click “Storage” in the left column, then “Pools”.
Click the three vertical dots to the right of your pool, and choose “Add Dataset” from the pop-up menu.
A new smaller window will pop up for creating the dataset.
In the “Name” text box give the share a name (because this is a starter share from which you can experiment, Fester used TestShare).
Leave the “Compression level:” drop down selection box set to Inherit (lz4).
Set the “Share Type” to whatever suits the type of clients on your network (Fester has mainly Windows machines so I set this to Windows).
Leave the “Case Sensitivity” drop down selection box and “Enable Atime” at their default settings as shown.
Now click the “Save” button.
The dataset will now be created and you should see something like this. If you don't see your newly-created dataset, click the > next to your pool name.
Click the three vertical dots to the right of your dataset, and select “Edit Permissions” from the pop-up menu.
A new window will pop up for changing the permissions of the new dataset.
Leave the “Apply User” tick box at its default setting (with a tick).
In the “User” drop down selection box select the new user you created a moment ago (in Fester’s case this was TestUser).
Leave the “Apply Group” tick box at its default setting (with a tick).
In the “Group” drop down selection box select the new group you created a moment ago (in Fester’s case this was TestGroup).
Set the “ACL Type” radio button to match the clients on your network (Fester has mostly Windows machines so I set this to Windows).
Put a tick in the “Apply permissions recursively” tick box. When you do this, you'll see a pop-up warning box.
Put a tick in “Confirm”, then click the “Continue” button.
Now click the “Save” button.
Share Creation
Now we need to create a SMB share. On a network that utilises predominately Windows or macOS clients this is a good choice.
Click “Sharing” in the left column, then “Windows (SMB) Shares”
Click the “Add” button.
A new smaller window will pop up.
In the “Path” section, you can type in the path (it's /mnt/tank/TestShare
in this example), or click the folder icon on the left to browse.
The “Path” text box should now display the chosen dataset.
Do not tick the “Use as home share:” tick box at the moment.
Give the share a name in the “Name” text box.
Do not tick the “Allow Guest Access:” tick box.
Now click the “Save” button.
You will now be asked if you wish to enable the SMB share service. Click the “Cancel” button.
You should now see your newly-created share.
SMB Configuration
Now click “Services” in the left column, and scroll down to find SMB.
Click on the little pencil next to the “SMB” service.
A new window will pop up.
The NetBIOS name will already be present in the “NetBIOS Name” text box.
In the “Workgroup” text box (3) type in the name of the workgroup you want to use on the client machines (Fester used T ESTWORKGROUP because it is an experimental starter share). If you don’t know your Workgroup then skip to the relevant section on how to do this.
Type in a good name for the SMB share in the “Description” text box.
Do not alter the default values of the “DOS charset”, the “Unix charset” and the “Log level:”.
Leave the “Use syslog only” at its default (no tick).
Make sure the “Local Master” tick box is ticked.
Leave “Domain logons” unticked.
Leave “Time Server for Domain” ticked.
Leave “Guest account” at nobody.
Do not put anything in the “File mask” and “Directory mask” text boxes unless you really understand UNIX permissions (Fester can’t help you here).
Do not tick the “Allow Empty Password” tick box as this weakens the security of the share.
Leave the “Unix Extensions” and “Zeroconf share discovery” tick boxes as they are.
Untick the “Hostnames lookups:” tick box otherwise you will keep getting a name mismatch error.
Leave the “Allow execute always” tick box in its default setting (with a tick).
Fester has no idea what the “Obey pam restrictions:” setting actually does. I just leave it ticked, but I have no idea how it should be set.
Don’t tick any of the IP address text boxes in the “Bind IP Addresses” section.
The “Idmap Range Low:” and “Idmap Range High” settings Fester does not touch as I don’t know what they do.
Now click on the “Save” button.
Do not turn on the SMB share service yet. We first need to check if the Workgroup on the Windows client is set correctly.
Windows Client Configuration
Click on the “Start” button and go into the “Control Panel” in Windows and select “System and Security” (this was on a Windows 7 machine).
Now click on “System”.
In the “System” page we can see the Workgroup is set to TWERKGROUP (1). This must be changed to match the Workgroup name you created in the SMB settings a moment ago (in Fester’s case this was TESTWORKGROUP).
Click on “Change settings” blue text (2) to access the screen where we can change the Workgroup name.
You will probably be asked for the administrator’s password at this point.
A smaller window will now pop up.
Click on the “Change” button.
Another window will now pop up.
Change the text in the Workgroup text box (1) to the one you created in the SMB settings page (in Fester’s case this was TESTWORKGROUP) and click the “OK” button (2).
Yet another window will pop up showing the Workgroup has now been changed.
Click the “OK” button.
A message window will now appear telling you the changes will be implemented when the computer is restarted.
Click the “OK” button.
As can be seen from the next screen shot the Workgroup has been changed to “TESTWORKGROUP” (1).
Click the “Close” button (2).
The system will now ask to be restarted. This must be done before going any further.
Close any open windows, save and close any open programs, etc.
Now click on the “Restart Now” button.
That’s the Windows Workgroup configured.
The client computer will now reboot, when it does log back into the FreeNAS GUI.
Enable SMB Service
Now click “Services” in the left column, and turn on the SMB share service.
Give the server some time to get the share up and running, then it is time to map the network folder to a drive letter.
Mapping the share to a drive letter
On the Windows client click on the “Start” button and go into “Computer” (this was on a Windows 7 machine).
This should bring up a window that shows all the hard drives and any other devices connected to the Windows computer.
Click on the “Map Network Drive” button.
From the “Drive:” drop down selection box (1) chose the drive letter you wish to assign to the shared folder (Fester accepted the default Z letter).
Now click the “Browse…” button (2).
This will cause a window to pop up.
Navigate to the location of the shared folder by clicking on the server (in this case TestNAS1) (3) and then clicking on the shared folder itself (in this case Fester’s TestShare) (4).
Now click the “OK” button (5).
The shared folder’s path name should appear in the “Folder:” text box (6).
Tick the “Reconnect at logon” Tick box (7).
Now click the “Finish” button (8).
At this point another window will pop up and ask you for the username and password for the share.
The name of the server is shown next to the text at the top of the window (1).
Type in your username in the first text box (2) (in Fester’s case this was TestUser).
Now type in your password in the second text box (3) (in Fester’s case this was test).
If you don’t want to type in your username and password exact time you log into your client machine then tick the “Remember my credentials” tick box (4).
Now click the “OK” button (5).
If all has gone well you should find yourself in the shared folder. Here you can create other folders and save files. Test this to make sure there are no permissions problems.
The shared folder will now appear as another drive on your system and should look something like this.
That’s the starter share done.
If you want to play with the permissions for this share then feel free. It is the only real way to learn about these things.
Remember the permissions for a share on Windows clients are in two parts.
Part one is the “Share” permissions and part two is “NTFS” permissions.
Share Permissions
“Share” permissions relate to the permissions of the actual shared folder on the server.
Be very careful changing these. The FreeNAS GUI will stop you making most catastrophic changes to the permissions that would otherwise break the share.
However, if you go behind the GUI to the command prompt you could really mess things up. Do not use the chmod command here or you will probably break the share. Use the getfacl and setfacl commands.
Another way you can alter the “Share” permissions is by using an application that runs on the client specifically for this purpose. I have not used any of these programs so I cannot comment on how useful or easy they are to use. However, you still need to be careful when using them because you are still going behind the FreeNAS GUI here.
NTFS Permissions
“NTFS” permissions relate to the permissions you set for the shared folder on the client side through the Windows OS.
It is considered good practice (this is debateable) to leave the “Share” permissions as they are and lock down the share using NTFS permissions. This has the advantage of controlling the share regardless of how it is accessed (i.e. locally or via a network).
It is much easier for the beginner and those that are unfamiliar with Linux or FreeBSD to configure permissions in this way as the permissions are controlled by a series of tick boxes (not cryptic commands). As long as you understand what each of the settings mean you should be fine.
However, be careful as it is possible using the “Everyone” group to lock yourself out of the share (Fester did this and could not regain control of the share).