\n\n\n\n
A little preface: I’m writing this post from the perspective of a Linux user. My home network consists mostly of Linux computers but there is also one Mac and one Windows computer who should be able to access the NAS. Their access is limited to reading from it so I’m not going to spend much time on Windows- or Mac-specific setups (although we will cover everything a simple home NAS should require).<\/p>\n\n\n\n
Linux Permissions<\/h2>\n\n\n\n
For our discussion about mounting shares it’s useful to know a little bit about permissions under Linux.<\/p>\n\n\n\n
By default, files and folders under Linux have permissions for three kinds of users: the owner, the owning group and everybody else. For each kind of user permissions can be any combination of read<\/em>, write<\/em> and execute<\/em>1<\/a><\/sup>. For example, when you run Permissions can also be written in octal form where a 4 corresponds to read<\/em>, 2 to write<\/em> and 1 to execute<\/em> permissions. So ‘rwx’ of the owner would be 4+2+1=7. The entire set of permissions rwxr-x— is then 760.<\/p>\n\n\n\n While the meaning of read, write and execute is quite obvious for files, it may not be as clear for directories. In short, execute<\/em> permissions for a directory allow you to traverse the directory but it gives you no other rights for the directory. For example, consider the file path \/A\/B<\/em> (folder A lives in root, folder B lives in folder A). If you only have execute permissions for A but full permissions for B then you can traverse A to get to B (e.g. with While the permissions discussed above are useful they don’t allow for very fine-grained control. More granular permissions can be managed with Access Control Lists (ACLs). They allow you to set custom permissions for individual users and groups. See here<\/a> for more information.<\/p>\n\n\n\n On our RPi files are saved using Linux permissions (because our operating system Raspberry Pi OS is a flavour of Linux). But Samba has to deal with Windows, Mac and Linux clients, which use different types of permission setups. Thus, Samba has to translate between Linux permissions and the native permissions of the client2<\/a><\/sup>. To achieve that Samba sometimes uses ACLs to store the desired permissions.<\/p>\n\n\n\n Samba was originally created for Windows. So even though we run Samba on a Linux server, it was originally intended to service Windows clients. Thus, a Windows computer connecting to the Samba server should correctly see file ownership and permissions.<\/p>\n\n\n\n Macs are not originally supported but there is an extension called fruit<\/em> which should allow for better compatibility between Samba and Macs. See here<\/a> for more information.<\/p>\n\n\n\n By default Linux file permissions are not supported so a Linux computer connecting to the Samba server will not see file ownership and permissions correctly.<\/p>\n\n\n\n In the original Samba version, SMB1, this was addressed with an extension to the protocol called Unix Extensions<\/em>, which correctly transmitted file ownership and permissions to Linux clients. SMB1 was not very secure though, so Samba versions 2 and 3 were subsequently published and SMB1 was deprecated. Unix Extensions<\/em>, however, are only available for SMB1. A set of extensions called SMB3 POSIX Extensions<\/a> is intended to make SMB3 better compatible with Linux (and other UNIX variants) but these have not yet been published (as of December 2023 when I’m writing this).<\/p>\n\n\n\n So Linux’s permissions system is not readily supported by Samba. Moreover, the way Greyhole is implemented requires Unix Extensions<\/em> to be turned off. What that means is that we can’t rely on Linux permissions to control file access on our NAS (at least not when we’re using Linux as our main OS). Instead we’ll have to rely on Samba’s built in access control mechanisms.<\/p>\n\n\n\n Now let’s get to restricting access to shares. There are quite a few options we can play with. For a full list have a look at the man pages of smb.conf<\/em><\/a>. One option that’s quite important is the option read only<\/em>. As the name suggests, it only allows users to read from a share but not to write to it. By default the option is enabled, so nobody can write to a share. How do we activate or deactivate read only<\/em> or some other option?<\/p>\n\n\n\n There’s a configuration file for Samba which is normally placed under \/etc\/samba\/smb.conf<\/em>. That file has multiple sections that start with square brackets, for example [global]. Each of the […] sections defines a share, with the exception of [global] which contains global settings and default values that apply to all shares in the configuration file. So one of the sections may be [Photography] and all options underneath it only apply to that share. The share-specific options overwrite any conflicting options in [global]. For example, a Samba share used by Greyhole could be defined as follows:<\/p>\n\n\n\n path<\/em> indicates where the share should be saved. The values shown above for vfs objects<\/em>, dfree command<\/em>, wide links<\/em> and follow symlinks<\/em> are required by Greyhole3<\/a><\/sup>. Finally, there’s the option read only<\/em> we discussed above. Setting it to No<\/em> makes the share fully accessible to all users.<\/p>\n\n\n\n Most of the remaining access control options can be split into two categories: user- (and group-)based controls and file (and directory) permissions-based controls. <\/p>\n\n\n\n This set of controls allows us to restrict or permit share access of certain users. We’ll have a look at the following options:<\/p>\n\n\n\n Let’s start with write list<\/em>. This option gives the specified users read-write access to a share, even if the share is marked read only = Yes<\/em>. So if we go back to the [Photography] example the settings below will allow user mpr<\/em> to write data to it and everybody else to only read data from it (remember, by default a share is read only).<\/p>\n\n\n\n Any users specified in read list<\/em> will only get read access to a share (even if read only = No<\/em>). <\/p>\n\n\n\n Option valid users<\/em> allows you to specify which users should be able to access the share. If a user is not on the list then they won’t be able to access it (e.g. mounting it will fail). Option invalid users<\/em> is similar but specifies which user should not be able to access the share.<\/p>\n\n\n\n There are a few additional options that I’ve chosen to ignore here. One is guest ok<\/em> which allows users without a Samba username and password to log in as a guest. Also, options force user<\/em> and force group<\/em> can be quite useful (but maybe not so much in a simple home NAS). See the link to the man pages above for details.<\/p>\n\n\n\n These options allow for more fine-grained control over the permissions with which files are created. However, if you’re not careful it’s quite easy to mess up access to your share. Also, without Unix Extensions<\/em> not all settings work as expected. So I’ll only discuss a very basic usage of these options. We’ll look at<\/p>\n\n\n\n Let’s start with option create mask<\/em>. This option allows you to influence the permissions given to a newly created file<\/em>. For example, you could set create mask = 664<\/em>4<\/a><\/sup>. On Windows (and on Linux with Unix Extensions) these permissions represent a maximum. Say you want to create a file with permissions 7705<\/a><\/sup>, the actual permissions of the file will be 660. On Linux without Unix Extensions this doesn’t seem to work so well. In my tests create mask<\/em> determined the actual permissions of the file. So if you try to create (or copy) a file with permissions 770 it will still end up having permissions 664.<\/p>\n\n\n\n So while this option is not as useful for Linux as it is for Windows, it’s still nice to have. By default files are created with permissions 744. I use 644 for most of my shares because on a NAS used for storing data there’s really no need to make all files executable (in fact no files need to be executable on the share).<\/p>\n\n\n\n While create mask<\/em> let’s you define maximum permissions, force create mode<\/em> allows you to set a minimum. For example, if you set force create mode = 775<\/em>, a file you want to create with 754 permissions will end up having 775. Again, on Linux without Unix Extensions this doesn’t work. Your final permissions will be the higher of create mask<\/em> and force create mode<\/em>. For example, create mask = 664<\/em> and force create mode = 744<\/em> will result in 764.<\/p>\n\n\n\n Options directory mask<\/em> and force directory mode<\/em> work in the same way as create mask<\/em> and force create mode<\/em>. The only difference is that they determine the permissions of folders or directories instead of files. I use directory mask = 755<\/em> for most of my shares.<\/p>\n\n\n\n An example of a share that I’m using in my setup is shown below. Note, the 0 before 664 and 755 refers to the special and sticky permissions that we ignored earlier (and now ;-).<\/p>\n\n\n\n After copying data onto the NAS you may want to change file and directory permissions. On Windows you can change file permissions like you would on your PC. The new file permissions will be saved in ACLs on the RPi. I didn’t find a way to change permissions on a Linux client (without Unix Extensions).<\/p>\n\n\n\n Before we finish, let’s review something we only mentioned briefly in the previous post. In the previous post we used the command<\/p>\n\n\n\n to mount shares under Linux. Option user<\/em> refers to your Samba username on the Raspberry Pi. At first glance it’s not so clear what option uid<\/em> is for. Let’s try to mount a share (to which everybody should have full access) without option uid<\/em>.<\/p>\n\n\n\n Now let’s look at the ownership of the mount points for each of the shares. Share Photography<\/em> is mounted with uid=mpr<\/em> and share Scratch<\/em> is mounted without uid=mpr<\/em>. The other shares are not mounted.<\/p>\n\n\n\nls -l<\/code> you may see permissions like ‘-rwxr-x—‘. <\/p>\n\n\n\n\n
cd \/A\/B<\/code>) but you cannot list the contents of A (so no ls \/A<\/code>) and you cannot change any of the other files or folders in A. <\/p>\n\n\n\nSamba and Windows, Mac and Linux Clients<\/h2>\n\n\n\n
Samba Access Control Mechanism<\/h2>\n\n\n\n
![\"\"](\"https:\/\/mpr-projects.com\/wp-content\/uploads\/2023\/12\/Share_Permissions_1-1.png\")
<\/figure>\n\n\n\nUser- and Group-Based Controls<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/mpr-projects.com\/wp-content\/uploads\/2023\/12\/Share_Permissions_5.png\")
<\/figure>\n\n\n\nFile and Directory Permission-Based Controls<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/mpr-projects.com\/wp-content\/uploads\/2023\/12\/Share_Permissions_6-1024x491.png\")
<\/figure>\n\n\n\nChanging File Permissions<\/h2>\n\n\n\n
Mounting Shares with uid=username<\/em><\/h2>\n\n\n\n
sudo mount -t cifs \/\/192.168.50.210\/Photography \/mount\/point\/Photography -o uid=mpr,user=mpr<\/code><\/pre>\n\n\n\nsudo mount -t cifs \/\/192.168.50.210\/Scratch \/mount\/point\/Scratch -o user=mpr<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/mpr-projects.com\/wp-content\/uploads\/2023\/12\/Share_Permissions_2-1024x310.png\")