This article is part of a series about setting up a home server. See this article for further details.

In this section we will create accounts for each user that will access the server, create a folder for each user, make sure the permissions are sane, and configure the samba shares.

For home environments a single user account that everyone uses can be good enough. However I like to have some semblance of security to raise barriers for viruses (who knows what’s going to be connecting to the network), so I setup guest to be read-only and assign write permissions only to authenticated users.

But before we proceed…

One Caveat when doing remote administration in a NeatX session

For some reason NeatX breaks policykit, which means any buttons in control panel applets that require root privileges will simply fail to work.

The way around this is to run the applets with gksu. The most convenient way to do this in my opinion is to create a desktop shortcut.

Go to System > Administration, right click on the users and groups icon in the menu, and “Add this launcher to desktop”. Next, right click on the resulting desktop icon, click properties and in the “Command” field, prepend gksu so that it reads “gksu users-admin”.

Double-clicking on the icon should then prompt you for your password, and all the buttons will work. Hopefully in the future this won’t be necessary!

I also created desktop shortcuts for Disk Utility and Back In Time (root).

Adding the users

Creating users is simple enough, but afterwards we need to add the users to two groups – “sambashare” and “users” (you should be able to figure this out). After doing this, go to Advanced Settings > select the Advanced tab and change the main group to users.

The reason for changing the primary group is so that any files the user creates are also accessible to others in the users group – which will include anyone that we want to be able to access files on the server. If you want to keep files private it is best to leave the primary group as the user name. Old school Unix people tend to know this, but for Windows refugees the lower level Linux concepts such as user groups and file system permissions can seem a bit strange, as they work quite differently.

Folders and Permissions

The raid array in my home server is mounted at /media/data. I like mount points to be owned by root to avoid accidental tampering:
chown root.root /media/data
chmod 755 /media/data
The octal permissions are 755, which means read/write/execute for the owner, read/execute for the group and all other users. For newbies I must confess that the rwx permissions notation is easier to understand, but unfortunately I learned octal permissions and it’s become a habit!

Under the data folder I have a folder for each user. The owner of the folder is the user, and the group is users, as I want Mum and Dad to be able to see each others files:
mkdir /media/data/mum
chown -R mum.users /media/data/mum
chmod -R 775 /media/data/mum
Repeat this for each user (substitute the user for “mum” in the example above). Note the use of the -R switch which applies the command to all sub-folders and files.

If Mum wanted keep her files private, both the owner and group would be the user name, e.g.:
chown -R mum.mum /media/data/mum
And the permissions would be:
chmod -R 700 /media/data/mum
Remember to make sure the primary group is the user name as well.

Setting up sharing (Samba)

I’m not 100% sure I’ve done this the officially sanctioned way, especially since it involves the decidedly old-school method of editing smb.conf. However for anyone comfortable with the terminal I think it works perfectly well.

First open /etc/samba/smb.conf in your favourite text editor (my preference is vim). There’s no need to modify any of the configuration, so scroll down to the bottom where the shares are located. I always comment out the printer shares (print$ and printers), as sharing printers via samba is a fool’s errand in my opinion, just get a blimmin’ network printer.

My shares are setup as follows:
[Data]
comment = Raid5 array, backed up daily
path = /media/data
browseable = yes
read only = no
guest ok = yes

[Media]
comment = Media files for XBMC
path = /media/media
browseable = yes
read only = no
guest ok = yes


Some explanation is definitely needed. Firstly while [Data] allows guests and the share is not read-only, guests will not be able to write because of the file system permissions which only allow the owner and group to modify files. You may want to create a public folder with permissions 777, which would allow guests to copy files on to the server. Or you may want to set up a another share and change guest ok to “no” for the data share.

The backup drive is read-only because I don’t want anyone to modify files on the backup drive, and file system permissions are no protection due to it being NTFS (Linux doesn’t and really shouldn’t support NTFS permissions). It would be too easy to go back to a previous version of a file and accidentally save it, and I’m not sure how Back In Time would handle a backed up file being newer than the source. Altering a file in the backup would also change every linked copy, so basically writing to files on the backup volume is bad mmkay? It is shared only to make restoring previous versions convenient.

NFS?

I haven’t covered setting up NFS here, as Mum and Dad both run Windows machines. If you do decide to setup NFS it’s fairly straightforward, but to save yourself some pain make sure the user ID’s match on all machines – NFS matches uid and not the actual user name. Off the top of my head the packages to install are nfs-common and portmap, and the config file to modify is /etc/exports.

A final note on samba passwords

I have found that a login to the local machine is required in order for the samba password to be synchronised with the unix password. If after logging in you still can’t access samba shares with that account, use the command smbpasswd to set the password, e.g.:
sudo smbpasswd mum

If you need to restart samba you can do so with the command ‘service smbd restart’.

Next section – Configuring the backup system