Permissions of Linux file system and Samba

After my new solid state disk lost my linux server installation I had to find a solution to go on running my server on any kind disk or device. My seldom used USB stick now bridges the time span until my SSD returns from the producer. In this context I had to setup again the Samba share of my home server which I exlpaind in the last post. Now I got some new experiences with permissions and Samba which I want to exlpain now.

Actually my files are stored in ext4 Linux file system. Typically Linux or Unix file systems only have the model of only one owner, one group and the rest of the world (others).
As I want to share some of my files in my private network with other client systems, e.g. Windows, I'm using Samba, which is (not only) a windows conform file server. When Windows (or Samba) considers permissions of files, it does it with a much more complex concept. Finally the so called effective permissions are those permissions of a file being analyzed when a user wants to access it. The effective permissions are made up of the share permissions and NTFS permissions.
I don't want to explain how these permission concepts work (you can read this at http://www.mcmcse.com/microsoft/guides/ntfs_and_share_permissions.shtml). Instead I want to come to another Linux topic dealing with these different permission concepts of the different operating systems. As you maybe know NTFS permissions allow an administrator to adjust permissions on files very detailed. To overcome the simplicity of the user-group-others Linux file permissions model there are File Access Controll Lists (ACLs). In Combination with a special configuration of a Samba share you can configure permissions as much detailed as you can do it with Windows. But step by step.

First you have to do two things to work with ACLs:

• Install ACL tooling (sudo ap-get install acl)
• Mount the partition that contains the directory to be configured with ACLs with a special option. In order to do this open the file /etc/fstab (maybe you do a backup before editing) and add "acl" as another mounting option spereated by a comma to the entry for the corresponding partition. In my case the modified line lokks as follows:

UUID=<The uuid for the partition>   /media/data   ext4   defaults,acl   0   2

Now the task is again to create a new shared directory where different users can create, modify and delete files and directories. To do so first the directory is created.

$sudo mkdir /media/data/share

For the following steps it is expected to have a user_x (or any other ;-) ) and a group (maybe the group users) where all users belong to that shall be allowed to work with the shares. Now the owner and group of the directory is changed as follows.

$sudo chown -R user_x:users /media/data/share

To let all (by different user that are members of the group users) created files have the group set before the SetGroupID (SGID) bit is set with the following command.

$sudo chmod -R g+s /media/data/share

When a user_x creates a subdirectory (e.g. /media/data/share/music) in the share directory, you will notice that the directory would have the permissions rwxr-xr-x, if you only configure permissions with chmod like this:

$sudo chmod -R g+rwx /media/data/share

If you have come to this point you will maybe understand the difference between NTFS permissions and Linux file permissions. When you create a new subdirectory with NTFS the permissions of the parent directory are passed to the new created directory by default. If you do this with a Linux file system like ext4 the so called user mask (umask) is used to determine the permissions to pass to the new created directory. By default the umask is set to 022. This means groups and others will be denied write permissions. Here the ACLs help to mediate between the different concepts when you share data with different systems.

The ACL tools give you options to query and change ACLs. The following paragraph shows you how you can get the actual ACL for the music directory, that you maybe created directory.

$getfacl /media/data/share/music
# file: media/data/share/music
# owner: user_x
# group: users
# flags: -s-
user::rwx
group::r-x
other::r-x

You see that user_x is the owner and only he has the option to read, write and execute files. Members of the same group only are allowed to read and execute files. This means the user user_y also belonging to the group users, won't be able to create files in that new created music directory.

To let new files and directories inherit special permissions at creation point you can set so called default permissions that will be applied to new created files and directories. You can do it with the following command:

$sudo setfacl -Rdm g::rwx /media/data/share

The result can be checked with getfacl again:

$getfacl /media/data/share
# file: media/data/share
# owner: user_x
# group: users
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

If you create now the directory /media/data/share/videos you will see that the default permissions have been applied to the regular permissions of the directory. This is the base ACL configuration to be done when you then come to Samba.

In my last post I wrote the following two lines to be added to a share declaration in the file /etc/samba/smb.conf to get the multi system share solved.

create mask = 0775
directory mask = 0775

But with the ACLs as a tool for permission configuration and another option in Samba it is much better to configure permissions. Actually it is not really elegant to once setup permissions via linux tools and then do the same work again in a samba configuration file. It would be more comfortable when we could use our ACL configuration again. Fortunately I discovered the following two Samba settings to use the ACLs:

inherit permissions = yes
inherit acls = yes

This is the replacement for the above mentioned two lines. With setfacl you could also configure more special permissions like you would do it with NTFS. Here only a few examples:

$sudo setfacl -Rm u:bob:rwx /media/data/share

The user bob gets read, write and execute permissions, although he maybe isn't a member of the group users.

$sudo setfacl -Rm g:guests:r-x /media/data/share

The group guests gets only read and execute permissions. Assumed that others would haven't any permissions this makes sense.

I hope I could explain the problem and the solution for, of sharing data over different (file/operating) systems in a understandable way. If anyone discovers a mistake please let me know of it.

Home Server Setup - The Second

Last year i bought a sweet small cube that should be my new home server, running with linux, to do all the stuff I want to do at home. This post will be about the second setup of this server. The first installation was my first "Linux server experience". As I was a little bit frightened to fail on the command line I installed a desktop edition of ubuntu. A friend who introduced me into the Linux world always said: "A server with a GUI actually isn't a real server!". Of course! But I felt good with that and now as I got some experience with Linux on my server I am sure that I will make the whole "command line server thing" - so I'm using the Ubuntu Server edition.

The original reason for this post is the setup of the server relating to sharing media files with serveral users in the home network. As I had to discover there were still some problems on which I had to spend much time to solve them. So to give it a name: I wan't to tell about Samba and further file administration problems.

Before I can start with the linux specific stuff, I will explain the environment and the conditions in my home network. There are actually only two users: me and another one. I have, as one can imagine, a Linux machine and he (the other one) has a Windows machine. Although it doesn't effect the problem directly I have to mention that the other user uses a very well known smartphone of Apple and therefore also iTunes. But this is another problem. The server runs with Linux, too. Both client machines shall have access to shared directories on the server, for instance for:

• music
• videos
• pictures
• documents
• backups.

That is to say, we both use the same media directories with different programmes from different platforms.

Now to the server side. The media data to share is stored on a RAID 1 array mounted at /media/data owned by the root user. The first steps to take are about creating the directories you wan't to share.

sudo mkdir /media/data/music

sudo mkdir /media/data/videos

... (also for the other directories)

The next step is to set up the users and groups that will be allowed to access shared media data. In this setup I will create the users user1 and user2, and the group share_media. Every user in this group shall get access to the data.

sudo groupadd share_media (create the group)

sudo adduser user1

sudo usermod -a -G share_media user1

... repeat the procedure for user2

At the moment the directory /media/data still is owned by the user root and the group root. To let the subdirectories be accessed by users of the created group, the directories have to be assigned the group share_media.

sudo chgrp -R share_media /media/data/*

This assigns the group to all children of /media/data. In my case the directory lost+found is also a child which should be owned by the root user. In this case you should replace * by the special sub directory name.
Now the time is right for installing Samba, a server that enables Linux to share files or directories with other Windows, MAC OS or Linux machines.

sudo apt-get install samba

For configuring Samba you have to open the configuration file /etc/samba/smb.conf in your favourite editor. I do it with vim. How vim works you can see here linuxconfig.org/Vim_Tutorial. Because the owner is root you have to prepend sudo again.

sudo vim /etc/samba/smb.conf

Typically many debian (the ancestor system of Ubuntu) configuration files consist of

• comments marked by the sign "#"
• sections surrounded by square brackets, example: [section name]
• settings in the form of: key = value

Then you append your declaration for your shared directories at the end of this file. You may give some comments before that. You do this analogously for the other shared directories.

[Shared Music]
comment = A shared directory for music on the server.
path = /media/data/music
writeable = yes
browseable = yes
guest ok = no
valid users = @share_media
create mask = 0775
directory mask = 0775

Actually the last two lines were the most difficult thing costing me much time to figure out that I had to set these lines. The explanation for this comes a bit later when I talk about file permissions. Although we already have set unix passwords for our users we still must set up users and passwords for Samba. You do it like the following line shows.

sudo smbpasswd -a user1 (then type in the password for user1 again)

... repeat it for user2

Now you can restart the Samba server to get the changes applied.

sudo service smbd restart

When you try to access the shared directory from another machine in the network you should be promted to type in your user name and password. Actually without the mentioned second lines in the Samba share configuration you would only be able to read the shared directories. So now I will explain what these lines are about.

The typical umask (see en.wikipedia.org/wiki/Umask for understanding the term) is 0022 (or shorter 022). This means when directories are created the default permissions are rwxr-xr-x. So the owner (first 3 signs) is able to read, write and execute (when it is a directory the x means you can access it). Users in the same group (second 3 signs)  and other users (last 3 signs) are only allowed to read and to execute.

For the shared directory this would mean: When user1 creates a sub directory, user2 is not allowed to write in that directory (create files). This is not the way that I need it. So I had to define an other mask for Samba. The mask system used in smb.conf is another one than umask. There you still have 4 positions with numbers but each number is the sum of the 3 granted rights:

1. read with number 4
2. write with number 2
3. execute / access with number 1.

So e.g. 7 means 4 + 2 + 1 (everything allowed) and 5 means 4 + 1 (read and execute). The line (0)775 means then analogous in the symbolic representation of permissions rwxrwxr-x.

Until now you have declared how Samba should handle the share and modification operations (rwx). But the shared directories still have the default permission values. These have to be set now.

sudo chmod -R g+rws /media/data/* (take care for lost+found explained above)

That's it. Now you should be able to create, modifiy and delete directories and files with different users from different systems.

Android und Maven

In einem aktuellen Projekt habe ich mit Webservices und Android zu tun. Wenn ich bisher mit Java EE zu tun hatte, habe ich Maven als Projektverwaltungstool benutzt. Nun möchte ich auch das Android-Projekt von Maven verwalten lassen. Im Netz habe ich unter folgendem Link einen extra Archetype für solche Maven-Projekte gefunden.
https://github.com/akquinet/android-archetypes/wiki/android-quickstart-archetype
Dort ist ein ganz einfaches Beispiel beschrieben, wie ein solches Maven-Projekt aufgesetzt wird. Dies sieht wie folgt aus:

 mvn archetype:generate
  -DarchetypeArtifactId=android-quickstart
  -DarchetypeGroupId=de.akquinet.android.archetypes
  -DarchetypeVersion=1.0.7
  -DgroupId=your.company
  -DartifactId=my-android-application 

Dies funktionierte ohne Probleme. Danach kopierte ich die Dateien eines bestehenden Android-Projekts in das durch Maven generierte Projekt. Die danach aufgetretenen Fallstricke möchte ich in diesem Post kurz erklären.

1. Das ist zwar ein Standardfehler, bei meinen Android Projekten, aber er trat wieder auf. Wenn wieder mal Eclipse neu eingerichtet wird und dann das Android-Eclipse-Plugin für Android installiert wird, sollte man nicht vergessen den Installationspfad zum SDK zu setzen.
2. Ebenso ist der Pfad in der Maven-Konfiguration des Android-Build-Plugins zu setzen.
3. Das Build-Plugin fordert ebenso eine minimale Maven-Version, die ich ebenso nachinstallieren musste. Dies ist die Version 3.0.3.
4. Im Android-Manifest sollte man die benötigte Android-API-Version (android:minSdkVersion)noch prüfen.