This post is mostly for myself, as it contains some code that I am using on a lot of servers and will be using on new installations again, most likely. Often the most difficult things are rights management and file permission management, and it isn't very hard once you know how to do it. Hopefully this will help some others as well. I've added a lot of explanation so other people can benefit from this as well, but all I really care about myself is the block of code below, which goes into the /etc/samba/smb.conf file on Linux;

 

Fileshare definition code sample (adjust to requirements)

[fileserve]
# hosts allow = 127.0.0.1, 192.168.124. EXCEPT 192.168.124.251
# hosts deny = 0.0.0.0/0
path = /fileserve/
writable = yes
browsable = yes
printable = no
guest ok = no
create mask = 0777
directory mask = 0777
force user = nobody
force group = nogroup
veto files = /.DS_Store/.Trashes/Thumbs.db/
# hide files = /$RECYCLE.BIN/desktop.ini/
delete veto files = yes
valid users = john, jane, doe

 

A bit of explanation is in order here. The hosts allow and hosts deny thing is pretty self-explanatory; it defines exactly which IP addresses are allowed to get access to the fileshare, or not. This goes before user credentials are considered, of course. So even if you are an administrator and are supposed to have access, if you're coming from the wrong IP address, you won't be able to get in.

Path speaks for itself, and writable simply means exactly that - if you have access then you can write stuff to this share. Browsable or Browseable can be used to make a share invisible in the overview you get when you do 'net view' or when you look up a server in Windows Explorer and you get an overview of its available shares. Normally it makes sense to set this to yes. Printable is an option reserved for printers, and we really don't want to do this with fileshares.

Guest ok defines if it is a 'public' share - whether just anyone can get access to it or not. If you want this to be a public share then set this to yes and omit the setting for valid users. Otherwise set this to no and then set up users in Linux and add them to the samba password list using the smbpasswd command (see further down in this article). I've made these 2 items bold to show you that these two settings are linked to one another.

Create mask and directory mask have to do with the file permissions on the filesystem of the server. I tend to keep things simple - just complete and full open access settings. Maybe not the most secure but then Samba servers are usually set up in a closed LAN environment anyways, and access can be easily controlled by IP address/range and of course user credentials. You can adjust these parameters to match your needs if for example another service needs access to these same files, like for example a web server. You can use force user and force group to store files with a specific username/group identity as well, this can be useful for web services but also for making sure that multiple different user accounts with access to the files are 'treated equally' in regards to storing the files, otherwise they will be stored with the user account of the user that stored the files, which may cause some problems like when you want to overwrite or delete or move a file and the system says "you need permissions from user X to do this". I like to keep things simple so forcing the user and group to 'nobody' and 'nogroup' makes sense for most of the situations I set up my Samba servers in (closed LAN).

Veto files is a dangerous setting when used in conjunction with delete veto files = yes. With both set, the specified files will be removed from the fileshare and won't be allowed on. I do this in shared environments where Windows and Mac computers both work, otherwise Mac will litter the share with .DS_Store and .Trashes files and folders, and Windows will litter it with Thumbs.db files (thumbnail cache files for pictures), and this can get pretty messy. It is a setting that you have to be careful about, though. If you make a wrong setting here you could wipe your files.

Hide files speaks for itself, of course, since it just hides files/folders that match the pattern given. They aren't "hidden" like you normally see in Windows where you can just open them anyways - they really will appear to not exist on the client-side when you set this option. So this can cause problems if you hide the $RECYCLE.BIN folder and Windows requires it for some reason. It won't be able to make the folder and it won't be able to find it - it won't be there as far as the client is concerned. Of course it will still be there on the server but Samba will not show it - it will be hidden completely, not just "hidden" but REALLY hidden.

 

User management, adding a user account

The idea with user management here is to create a user in the Linux operating system, and then add the user to a special password list for Samba. So first add a user to the OS, and then add the user to the password list for the Samba filesharing service;

adduser usernamehere
smbpasswd -a usernamehere

Note please that you must not use spaces in the username. If your user account on for example Windows does have a space in it, read on to learn how to map a user with a space in it to a Linux user without a space in it for the Samba filesharing service. It's better to handle it that way, and it's quite easy to do.

 

Map user account with spaces to a Linux account

Edit the smb.conf file in /etc/samba/ and under the '[global]' section (near the top) add this line:

[global]
username map = /etc/samba/usermap.txt

 

The file usermap.txt will contain the mappings from Linux user account without spaces to a user account that does have spaces;

linuxuser = "Spaced User"

 

With this done you can reload the Samba service with /etc/init.d/samba reload or service samba reload and it will then automatically translate "Spaced User" to "linuxuser". The quotes by the way are there to ensure that Samba understands that the words Spaced and User are not 2 separate users, but 1 single user with the name Spaced User.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Prove that you are not a spam robot: * Time limit is exhausted. Please reload CAPTCHA.