@bulsatar It's not hard to get bogged down on share issues as it's a potentially complex subject (see for example:
https://forums.freenas.org/index.ph...-configure-share-permissions-freenas-9.35276/
https://forums.freenas.org/index.php?threads/methods-for-fine-tuning-samba-permissions.50739/
https://forums.freenas.org/index.php?threads/how-to-edit-cifs-permissions-from-the-cli.40594/
https://forums.freenas.org/index.php?threads/guest-permissions-on-cifs-share.27391/ )
One idea to be clear about is the meaning of the term "guest access" or "guest account" when referring to SMB shares created in FreeNAS. The "guest account" is in-built and by default is "nobody:nogroup" in both FreeNAS and Linux. You don't need to add an additional user & group to use this concept.
Creating a SMB share that all your home windows users can access without credentials should be straight forward, and by implication if your SAMBA server is configured to use "security = user" then it must be by setting "allow guest access" on the individual SMB shares. But there is a gothca to be aware of, which can be summarised as:
In Windows the client's username and password is automatically sent when it browses for shares - this is done without the user's knowledge. That forces Samba to deal with the sent credentials even though it's a guest share that requires no authentication.
When that username is passed Samba will search through it's password database for that user:
- If there is no match to the username the client user is tagged a "Bad User" and converted ( mapped ) to the guest account which by default is "nobody".
- If it finds a match to the username and there is a samba password that matches the one sent by the Windows client then the Windows user automatically gains access although not as an anonymous user which is why you needed to add "force user = nobody" to your share definition.
- If it finds a match to the username but the samba password does not match exactly the password that's automatically sent by the Windows client then you will be prompted for a password - even for a guest share.
The idea of using "
force user = nobody" becomes important if you want the same SMB share to be accessed from a Linux client using a
mount -t cifs ..... command or a /etc/fstab entry.
If I've understood your OP correctly, you want Windows users to access the share as guests together with at least one linux client. This scheme might work for your case.
If the dataset you wish to share was Data_Storage/Movies, then I would make its owner and group "nobody" & "nogroup" and set permission type to windows. Ensure the SAMBA service "Guest Account" is set to "nobody".
Create a "Windows (SMB)" for the "Data_Storage/Movies" dataset, setting both "Apply Default permissions" and "Allow Guest Access", named Movies, for example. The important extra here is to add the text "
force user = nobody" in the Auxiliary Parameters box using advanced mode.
Check you Windows users can access the share without needing to login. They will have the perms set on the dataset for the "nobody account" (defaults to read,write,execute)
To mount the same SMB share in Linux you will need to have the same account (uid/gid) defined on both linux and FreeNAS, e.g: Fred with uid=1010 and gid=1010.
On linux mount the SAMBA share using the Fred account, the FreeNAS passwrd for Fred will be required, e.g :
mount -t cifs -o vers=2.1 -o user=Fred,uid=1010,gid=1010 //<FreeNAS ip>/Movies /home/Fred/CIFS
or its /etc/fstab equivalent. The "
force user = nobody" in the SAMBA share will effectively turn Fred into "nobody".
This scheme fudges the issue of the difference between linux and windows permissions which are based on completely different models. OK if the share is read-only, but could cause inconsistencies if both Linux and windows users have read/write access.
An alternative, and possibly preferable scheme for better performance on your Rpi over what is a 100Mb/s network, is to share the same data in two different ways. Create an NFS share for Linux clients, and Windows share for Widows clients on the same dataset. This is safe if only one of the two protocols is configured for read/write access.
The CPU utilisation for a NFS connection should be lower than using CIFS on your Rpi and you should see higher read speeds than if CIFS was used. If you set the FreeNAS NFS service to use NFSv3 then it will authenticate against your Rpi host IP, there's no need for users to be in sync on both FreeNAS and Linux. If the NFS share, for example, on the dataset "Data_Storage/Movies", is read/write then you would have to make the SAMBA share on "Data_Storage/Movies" read-only and allow guest access as previously described.
