Linux Mint and Windows Network Share Investigation of Permissions

Update 2019 – It's quite simple: The file container (dir) stores the file's namespace and inode link so IT'S permission affects the access to files within that folder ALSO, not just the individual file's permissions and/or ownership!! That's why the default install directory/file permissions for most dirs/files in any installation are 755/644 resp. – a best compromise of security over access for most situations! You need x = execute to traverse a directory even if you cannot view it's contents. Root/sudo group can do (almost) anything to anyone's dirs/files (see chattr etc.)

755 = rwx;rx;rx. Only Directory owner has read,write,exe to directory contents; all users have read and traverse.

644 = rw;r;r. Only file owner has read,write; all users have read only. This prevents non program or binary files being set to executable as default.


I left the last new Mint Install Post with a question I want to answer for myself and probably many others too, that have struggled with the logic of this fundamental requirement:

What about mixed Win/Lin user environments with multiple users accessing each other's shares?

[Ad: 2016: I have since found out the fundamental reason, after all these years, for mine and lots of other IT students confusion being an understandable but incorrect assumption and lack of knowledge on how file system directories and files are designed and work. I have put this critical info in my Course Material PDFs – top menus. I did not find all the answers on the Internet, but the major missing facts in a quality linux Admin book. It still took much practise to become familiar with combining all the required elements of file permissions AND Samba configuration!] 

File permissions and access has always been an area that confused me, and still does today, most of the time in real environments when PCs don't communicate the way you expect them to: even being aware of the "theory of security granularity" – relating to the level of access allowed to files and folders on a network being in two distinct stages:

  • Network access privileges
  • Filesystem access privileges

Whether that's out of date info for Linux and Samba now, I don't know, but it used to be that the actual access level was a "combination sum" of the two settings from what I vaguely remember reading somewhere– or maybe it was just for Windows systems?

The idea was that Network access can be a bit "looser" in terms of user level access to allow viewing the actual shared system in the first place – e.g: without having to have an account on the networked host – before user specific Filesystem access privileges are granted by "logging in" to actually access/change data on the system – i.e. an account with set permissions.

On my home network where I have the same username and password on all Win and Lin PCs, I usually just make a /Share folder on the Mint box, and change its ownership to my user, stevee:

sudo chown -R stevee /Share

Once the user stevee has been added to the PAM DB (on Raspbian or Mint):

sudo pdbedit -a stevee

or just added as an smb user (on Mint only) using:

sudo smbpasswd -a stevee

and the /Share added to /etc/samba.smb.conf with as open as perms as possible just to get going:


path = /Share

writeable = 1

browseable = 1

The share is usually immediately visible across the network from any PC, and as mentioned, with Mint, any local permission changes are instant without constantly restarting samba, and that's about as easy as networking gets for a basic single user Win/Lin network.

Ok so far, but group access is set as root still – only user stevee is the owner – but because of fully open perms 777, Everyone can see the share remotely even if they can't write to it as it is owned locally by user stevee and group  BUT possibly write/delete it if they have an account on that PC.

Let's say you now need a /Share on the Mint PC, but have different Lin and Win users needing access locally and from different mixed PCs, but with the sensible restrictions of not being able to delete or change others folders or files, but be able to see, traverse, execute or copy them.

What are the permissions you need to set and where? I'm not sure, so let's investigate.

To keep things as simple as possible, the Mint usernames and passwords have to be kept the same as the current users Windows ones for ease of connection – i.e. stevee, joe etc., in lower case for this Post example, so there are already accounts for these users setup on all PCs.

First, the Netshare is created as usual on the Mint root dir, which is owned by user and group root by default, so as root:

mkdir /Share

Dell531 stevee # ls -als /Share

total 8

4 drwxr-xr-x 2 root root 4096 Jul 3 20:13 .

4 drwxr-xr-x 30 root root 4096 Jul 3 20:13 ..

This has the default perms of 755 or rwx for owner (root), r-x for group (root) and r-x for everyone else. Trying to write to it, or any other shares that are owned by root, gives a permission decline notice in Win:

Similar in Mint:

So that's a baseline to try to understand later changes.

The addition in smb.conf for the new Group share is:


path = /Mintshare

writeable = yes

browseable = yes

read only = no

create mask = 0777

directory mask = 777

If you testparm this for syntax errors, you get the same valid settings stated:



path = /Mintshare

read only = No

create mask = 0777

directory mask = 0777

It stands to reason that for anyone else to be able to write to this directory, they would need to be in roots' group LOCALLY, disregardless of the Samba masks above, and have relevant permissions set on the LOCAL folder to do so OR have total free for all access for ANYONE to this –or any other – folder by setting a 777 permission locally.

To prove this, I will set the /Rootshare folder LOCALLY, as root, to 777:

Now anyone can write to /Rootshare:

The big problem with this is anyone can delete or change anyone else's files. NOT good. As stevee, I delete tom's file:

Sorry Tom, I accidentally deleted all your hard work…oops.

Obviously, we can't go giving all shared folders 777 local permissions, or give users membership of the root group, so can they be added to the same group as the owner of the directory to be shared, and still have relevant ownership and access? Seems straight forward enough in principle doesn't it?

Hmmm…, it doesn't seem to work quite like that, but nearly.

Each user is a member of his own group of the same name, but stevee is in other types, such as sambashare because he was the user created on install so has some Admin privileges too:

Note also that the first user added at install time (stevee) becomes this "quasi" Administrator. I say "quasi" because he does not have total root powers, else there would be no point creating a user at install other than root in the first place.

Still, it makes sense NOT to add other users to this "quasi" admin group – stevee.

So what about adding all required users to another users group, and having that user create the folder to be shared – that should work in principle eh, as all users will have possible group access at least so far?

First a recap on permission values from:


Common permissions:

  • 750 – The Owner may read, write and execute. The Group may read and execute. (but not write) The world may not do anything with this file.
  • 755 – Same as above, but the world may now also read and execute the file.
  • 700 – The Owner may do everything, the Group and the world may not do anything.
  • 640 – The Owner may read and write, the Group may read and the world may not do anything.
  • 644 – Same as above, but the world may now also read the file.
  • 600 – The Owner may read and write, the rest may not do anything.

Some "weird" permissions, mostly because they are broken or very rare:

  • 000 – Nobody may do anything with this file. Effectively archive the file. Maybe removing the file would be more appropriate.
  • 007 – The Owner and Group can't do anything, but the World can. I can't think of a situation where this would apply.
  • 100 and 300 – The Owner may execute but not read, so the execute will not work.
  • 200 – The owner may write, but not read. The only situation I could imagine is a logfile where some application may write to, but is not allowed to read the file.

There are some special permissions you can give, these permissions go into the zeroth field. You'd use chmod like this to set no special permissions: chmod 0750

  1. Sticky bit A value of 1. This bit is commonly set to directories and means that you may only remove file in such a directory that are owned by you. The filesystem /tmp is commonly set with that bit; everyone can write there, but you can only remove/rename files that are owned by yourself.
  2. Set Group id A value of 2. The file is executed as the Group of the file. Some groups have quite some permissions. Imagine /bin/rm (to remove files and directories) having a Set Group id bit, all users in the Group of /bin/rm may remove a whole lot of files. When you are using Set User id or Set Group id bits, you should be very sure you know what you are doing.
  3. Set User id A value of 4. If this permission is given, the program is executed as the Owner of the file. Could be dangerous; think of a PHP script that tries to reboot a machine…

So 4750 would mean the file may be executed by the owner and the group, and will be executed as the owner.

Imagine a script would have 4775 permissions and would be owned by root:users; a user could edit the script, and the world could execute it with roots permission!

Just to remind you once more; Set Group or User id bits are dangerous, know what you are doing when using them!


Can different users be added to the same group as the owner of a shared folder, so have the access permissions of that group? That way, permissions for each owner's file or folder – in the group folder – could be different from the other group members, which is what is required in most cases, where read and execute permissions of another user file is required, but with the owner retaining control of content and deletion. Users outside the group may need to be blocked completely.

From above then, the attributes for this case would be 750, or rwx (user); r-x (group); — (others)

First, add some users to Mint and the PAM DB so users have user level network login access recognition at least, before file permissions are considered:

Dell531 stevee # adduser tom

Dell531 stevee # pdbedit -a tom


Dell531 stevee # pdbedit -L









As mentioned, one way to group share may be to add all users to a common group, then make one group member the owner of the shared directory.

Are there any common groups already in place? Well, looking in the Users and Groups GUI, stevee is already a member of the sambashares group, and as all members would be accessing linux via smb, it makes sense to add all network members to the sambashares group. Let's make gavin the /Mintshare folder owner, but first, check let's what access stevee (quasi Admin, access by Win7 and Mint) has when trying to create a textfile, as an indication of any special quasi Admin powers, and for user matt:


and matt (access by Win8) have now?:

No access as expected for root ownership.

So changing ownership of /Mintshare to gavin and group sambashare:

Dell531 / # chown gavin:sambashare /Mintshare/

Dell531 / # ls -als /Mintshare/

total 8

4 drwxr-xr-x 2 gavin sambashare 4096 Jul 4 12:48 .

4 drwxr-xr-x 31 root root 4096 Jul 4 10:47 ..

The share cannot be written to by the users though.

The group needs write permissions also to gavin's folder to be able to create their own folders and files, so perms 770 need setting to make it writeable:

Dell531 stevee # chmod -R 770 /Mintshare/

Dell531 stevee # ls -als /Mintshare/

total 8

4 drwxrwx— 2 gavin sambashare 4096 Jul 4 12:48 .

4 drwxr-xr-x 31 root root 4096 Jul 4 10:47 ..

The problem at this point is that everyone can still delete each other's data.

Can data can be locked down now with permissions set back to 750, but for data that is inside the share folder using the wildcard leaving the original ownerships intact? It seems so:

Dell531 stevee # chmod -R 750 /Mintshare/*

Dell531 stevee # ls -als /Mintshare/

total 16

4 drwxrwx— 4 gavin sambashare 4096 Jul 4 12:56 .

4 drwxr-xr-x 31 root root 4096 Jul 4 10:47 ..

4 drwxr-x— 2 tom tom 4096 Jul 4 12:56 mattWin8

0 -rwxr-x— 1 tom tom 0 Jul 4 12:56 MattWIn8.txt

4 drwxr-x— 2 stevee stevee 4096 Jul 4 12:55 SteveVNC

0 -rwxr-x— 1 stevee stevee 0 Jul 4 12:55 steveVNC.txt

This is not quite as desired because only the owners of the files and folders can see and change their own data, because their groups are not sambashares, e.g. when stevee tries to view matt's folder:

The data in /Mintshare has to be group owned by the sambashares group, but not have data created by the users own group – how is that achieved? Research required.

I forgot about this method of using UGO forms for adding perms to data for each UGO case seperately! E.g.:

chmod -R g+w lab/

In that link example, the folder /lab is owned by the required group, so just the write permission alone can be added for group, not using the 3 digit 750 format alone.

Adding a recursive group write for the share folder itself /Mintshare, but then removing group write permission from users data inside the share, by using the Asterisk, seems to do the trick – but note – there has to be at least one folder written in the share for this to work:

chmod -R g+w /Mintshare/

chmod -R g-w /Mintshare/*

ls -als /Mintshare/

total 24

4 drwxrwx— 4 gavin sambashare 4096 Jul 4 14:00 .

4 drwxr-xr-x 31 root root 4096 Jul 4 13:16 ..

4 drwxrwxr-x 2 tom tom 4096 Jul 4 13:58 MattWin8

4 -rwxrw-rw- 1 tom tom 11 Jul 4 13:59 MattWin8SteveeW7.txt

4 drwxr-xr-x 2 stevee stevee 4096 Jul 4 13:56 SteveeWin7

4 -rwxr-xrw- 1 stevee stevee 9 Jul 4 13:56 SteveWin7andLocal.txt

I can create a directory as a user that can't be changed by others in the group, but NOTE that any FILES alone that are created in the /Mintshare groupfolder alone CAN be deleted, as group members need write permissions here in the first place to create their own folders!

Does it work as intended? User stevee on Win7 can't write to toms folder file – good:

User tom can't delete stevee's folder file either – good:

According to that link, there is a SetUID bit for groups also:

"So we have some examples of using chown and chmod to change the ownership and permissions to implement access control in Linux. However note that there are different ways to implement the access control requirements – we have considered just one approach. You may want to consider others, and the tradeoffs between them. Other things to consider include:

  • How to change the default permissions and ownership when files are created? (Hint: /etc/login.defs and umask)
  • How to make files that one user creates in a shared directory have the same ownership as that directory (as opposed to the user that created them)? (Hint: setuid)
  • When setting the group execute permission on a directory, does it restrict other users in that group from deleting files in that directory? (Hint: sticky bit))


So, what are the summary permissions here for future group shared use and testing? UGO numerical values are write(2) and execute(1) added to read (4) so a max of 7 per block. In this working, usable scenario, it means:

Shared Dir = 775 or  drwxrwxr-x (allows all group users to write files in the group owners folder)

User folders = 775 or drwxrwxr-x (set by recursive chmod -R g+w /Share/*) Allows group users own file creation/write access inside other users folders. Different from users default 755 drwxr-xr-x folder creation perms.

User Files in User Folders = 644 or -rw-r–r– (created by default by the user account)

Dell531 stevee # ls -als /Mintshare/

total 24

4 drwxrwx— 4 gavin sambashare 4096 Jul 4 14:13 .

4 drwxr-xr-x 31 root root 4096 Jul 4 13:16 ..

4 drwxr-xr-x 2 stevee stevee 4096 Jul 4 14:11 SteveeWin7

4 -rwxrwxrw- 1 stevee stevee 9 Jul 4 13:56 SteveWin7andLocal.txt

4 drwxrwxr-x 2 tom tom 4096 Jul 4 13:58 tomWin8

4 -rwxrw-rw- 1 tom tom 11 Jul 4 13:59 TomWin8SteveeW7.txt

As I can't see the Mint share – possibly until I reboot due to a lockup – I can test via SSH and su if users can access or delete other's subfolders and files. User joe cannot list or see stevees folder or files locally even though he is in the sambashare group, as they are appear to be only accessible via the network – just what is required!

Dell531 stevee # su joe

joe@Dell531 /home/stevee $ rm -v /Mintshare/Steve[TAB]

SteveeWin7/ SteveWin7andLocal.txt

joe@Dell531 /home/stevee $ rm -v /Mintshare/SteveWin7/*

rm: cannot remove '/Mintshare/SteveWin7/*': No such file or directory

joe@Dell531 /home/stevee $ ls -l /Mintshare/

total 16

drwxr-xr-x 2 stevee stevee 4096 Jul 4 14:11 SteveeWin7

-rwxrwxrw- 1 stevee stevee 9 Jul 4 13:56 SteveWin7andLocal.txt

drwxrwxr-x 2 tom tom 4096 Jul 4 13:58 tomWin8

-rwxrw-rw- 1 tom tom 11 Jul 4 13:59 TomWin8SteveeW7.txt

joe@Dell531 /home/stevee $ ls -l /Mintshare/SteveWin7andLocal.txt

I will logon to Mint locally as joe and check this.

Joe has local write powers to others files:

But no write powers via samba locally:

I will have to test this, but for now, at least I think I have a working solution to Win/Lin networked shares, provided users know they have to create their own directory in the common group share.

I'm sure there is a better way for professional admins to set this scenario up on a large scale, but at least I have a better understanding of the nuts and bolts of Samba sharing on linux beyond own usual requirements.

If you really want to use the GUI:
apt-get install system-config-samba



You can see what changes to smb.conf the GUI makes for this new share I created:

path = /SMBGUITest
writeable = yes
; browseable = yes
valid users = gavin, matt, stevee

Now it will be good to cross check the ownership/permissions of this folder and the sub files and folders these users create in it to see what they are. Note the valid users option.

Dell531 stevee # ls -als /SMBGUITest/
total 8
4 drwxr-xr-x 2 root root 4096 Jul 7 18:44 .
4 drwxr-xr-x 35 root root 4096 Jul 7 18:44 .. 

Well, it seems the GUI does not solve the Win/Lin share issue either, because the "user" cannot create a folder here either while the perms are 755 as shown! Root owns it, so back to the same issue I was trying to resolve at the start of this Post. Same issue for users locally:

Dell531 stevee # su matt
matt@Dell531 /home/stevee $ mkdir /SMBGUITest/Matt
mkdir: cannot create directory â/SMBGUITest/Mattâ: Permission denied

You still have to make a group member an owner and add the chmod g+w /Share commands as above for this to work so each user can create their own folder locally first, the no-one else can write to it anyway, as seen here:

gavin@Dell531 /home/stevee $ ls -als /SMBGUITest/
total 20
4 drwxrwxr-x 5 gavin sambashare 4096 Jul 7 19:18 .
4 drwxr-xr-x 35 root root 4096 Jul 7 18:44 ..
4 drwxrwxr-x 2 gavin gavin 4096 Jul 7 19:15 Gavin
4 drwxr-xr-x 2 gavin gavin 4096 Jul 7 19:18 Matt
4 drwxr-xr-x 2 stevee stevee 4096 Jul 7 19:18 Stevee

you also have to lock each user folder to 755 after creation too, else other group users can rename or delete it! What a hassle!!

I like the question that doesn't get answered:

"Interesting stuff, here's my situation. We have a public share setup for all staff to use, with all types of folders branching off from this public share. Most of our people are not very good with computers and can just do the basics. so to keep things fairly simple for all users I would like to keep the shares the way they are but, I would like to add a level of security to some (but not all) of the folders under the public share. I would like to be able to have some of the folders have a password, no user name. So if somebody clicks on a certain folder, they would then need to put in a password to continue on. I have read the samba text book cover to cover and can't find anything on this particular strategy. Any help that somebody can offer would be greatly appreciated. Thanks."

The issue here seems to be that a folder was setup in the simplest but most insecure way to allow quick local storage access for all – a common small company issue – by using chmod -R 777, so FULL LOCAL USER read/write/exe access to e.g. /Public, is made. Anyone can view and delete anyone else's folders/files in /Public but only on the local machine at this point.

For this folder to be network viewable and/or accessible it still needs to be written to /etc/samba/smb.conf with appropriate net permissions e.g:


path = /Public
writeable = 1
browseable = 1
create mask = 0775
dir mask = 0775 

So, /Public still belongs to root, but Others (everyone, world) now have local AND network read/write/exe access and can write more folders and files into it. Sub directories created in this /Public folder will have the default permissions of the user creator; 755 = readable and traversable by Others also; and default files created under /Public or the creators sub dirs will be default 644 = readable by Others also. BUT – everything is visible/deleteable to Others because of the /Public parent folder's permissions of 777!

So, without creating individual user accounts on the linux box – which he may already have for those users accessing /Public over the net because without that, and the non default

valid users = %S 

set, you get:


for a user that DOES NOT have an account on the server, so can't log in to the share UNLESS valid users = %S is commented out:

# By default, \\server\username shares can be connected to by anyone
# with access to the samba server.
# Un-comment the following parameter to make sure that only "username"
# can connect to \\server\username
# This might need tweaking when using external authentication schemes
valid users = %S

However, I found that I still cannot connect with this commented out if the net user does not have a local account on the samba server, even after restarting the service – as local account security trumps net access – users still have to have a valid local account with appropriate local permissions to access the system at all else there would be NO security at all.

Without creating smb users and/or moving individual users into common groups and/or sharing specific sub folders in smb.conf, it's not possible to have access to "some" already /Public folders with just a password, as 777 allows insecure access on /Public by definition. It's the users local account that provides folder and file security on the system – networked or not.

An alternative may be web access via WEBDAV, but that means using Apache for anonymous/password access.

He needs to do some reorganising to create local and smb accounts on this server for all individuals, then common groups for those users needing access to specific group common folders and changing the ownership of those folders to that common group using chown -R root:group /Public/groupdir1 or similar.

man smb.conf

security (G)

This option affects how clients respond to Samba and is one of the
most important settings in the smb.conf file.

The default is security = user, as this is the most common setting,
used for a standalone file server or a DC.

The alternatives are security = ads or security = domain, which
support joining Samba to a Windows domain

You should use security = user and map to guest if you want to
mainly setup shares without a password (guest shares). This is
commonly used for a shared printer server.

The different settings will now be explained.


This is the default security setting in Samba, and causes Samba to
consult the server role parameter (if set) to determine the
security mode.


If server role is not specified, this is the default security
setting in Samba. With user-level security a client must first
"log-on" with a valid username and password (which can be mapped
using the username map parameter). Encrypted passwords (see the
encrypted passwords parameter) can also be used in this security
mode. Parameters such as user and guest only if set are then
applied and may change the UNIX user to use on this connection, but
only after the user has been successfully authenticated.

Note that the name of the resource being requested is not sent to
the server until after the server has successfully authenticated
the client. This is why guest shares don't work in user level
security without allowing the server to automatically map unknown
users into the guest account.


Basic Users. Groups, and Permissions Info

There are 2 formats to change perms using # chmod – text and numeric – eg: # chmod g+r,o-rx / which adds a read permission for Groups, and removes read and execute perms for Others. To change all categories in one go, use a (All) eg # chmod a+w /file = chmod ugo+w /file

First, view a files current attribs: # ls -ld /file.txt

-rw-r–r– 1 root root 417416 2008-12-21 00:06 /file.txt

This shows a normal file, not a folder (no d at start), with rw- attribs for users; r– read only for Groups; r– read only for Others; Number of links a file has (1); owner (root); group (root); actual filesize in bytes B (417kB) [sector = 1kB = 2 x blocks of 512B]); date then time of creation

The numerical permissions work in 3 blocks of 3 in order of User, Group, Others in order resp. to a maximum sum of 7 per category (ie max attribute of 777 per file/dir = drwxrwxrwx for all Users, Groups and Others and the d refers to a directory) where 7 = rwx and is the sum of write(2) and execute(1) added to read (4) , so an attrib of 3 (=2+1) gives an attrib of write and execute permissions to a category eg chmod 733 /file gives Users drwx—— (1+2+4) privelege, Groups d—-wx— (ie 3=2+1), and Others d——-wx (ie 3=2+1 also) for a complete file perm of drwx-wx-wx to /file. So the numbers 0 – 7 give the 8 possible permissions: r,w,x,rw,rx,wx,rwx and null (0) = ———-

Try chmod 000 /testfile then look with # ls -ld to see, going through all numbers 100,200,300..700 to see the changes on the User attribs.