I've now got my ReadyNAS 314, installed a single WD Red 1TB (for now), and upgrade to ReadyNAS v6.1.8.
I've set-up my users, and started to work on my shares. However I confused between the Network Access and File Access...
Am I meant to configure the Network Access tab, to state what access each user/group has over network connections (i.e. SMB, AFP, etc), however how does this relate to File Access? Do I have to also set-up user/group permissions under File Access, or do they just inherit the settings I made under Network Access?
The linux system doesn't understand protocol access. It relies on file access and local users. By default, Linux rights are done with 3 parameters : owner, group, other ; that can take several values : 1=execute or go through, 4=read, 2=write, any addition of those values. So when you have to give a single user a right to a folder, you either change the folder's owner, or you create a group that all users that need access will share. This limits the things you can do with rights. I believe that Netgear added some things to be able to use ACL rights though, which gives more options than that.
Share rights (or protocol rights, or network access rights) are much more flexible (it can use linux local users, LDAP, DB users, user list... ; it can set rights per user or per group). But since linux doesn't understand them by default, the software that handles the protocol acts on a file access level, get the data it wants and then applies its permissions on it before delivering it on the network (you can think of it as a middle man if you want). This means that the weakest on the two sets of rights applies. If the FTP/SMB/AFP server that runs under a local linux user (each process on linux is runned by a user) is not authorized to access the files, it won't be able to transmit them. If it can access the files but your user is not allowed at the server/protocol level, you will be blocked too. That's why we rarely set file access rights unless we want to enforce a limitation (read-only for everyone for example).
I didn't speak about windows because, with basic concepts being the same, windows handles everything at the file level way more easily than linux does for SMB. I tend to authorize everything for everyone on the share rights on windows and locking with NTFS rights (because they give more control interestingly) while I do exactly the opposite with linux. Windows being an all in one solution for SMB/CIFS shares, that's more convenient like this (and in windows server, that's how it's meant to be since share permissions hidden in a submenu and grant everyone full control). That said when you install other more enterprise software you use a "system account" for the software and then create users inside it like for linux (Oracle server for example works like this).
Either way the least permissive of the two applies, and an explicit deny (clicking refuse, not just letting blank on windows, depends on software for linux) will result in a denied access even if the user is a member of a group that is allowed.
I'm interested in your post 'cause as a newbie (in both NAS and LINUX) file permissions are crucial (see my post here). I don't have a Linux background (unfortunately) so something that I say may sounds silly because of that.
So.. in your first post you say "the weakest on the two sets of rights applies" but after, in the next post, you say "Either way the least permissive of the two applies" (which means strongest, the opposite).
Also for me english is not my first language so I possibly have misunderstood something 🙂
So.. in your first post you say "the weakest on the two sets of rights applies" but after, in the next post, you say "Either way the least permissive of the two applies" (which means strongest, the opposite).
"Least permissive" is correct, and results in the most restrictive policy.. Personally I wouldn't use strong/weak to describe this. Strong implies inherently better (there is no value in weak encryption, unless you are wanting to do mass surveillance). However, more restrictive is not inherently better than less restrictive, and there are use cases where less restrictive is what you need.
