Nov 21

Samba: Simple and Secure File Sharing

Samba can be overwhelming. Especially since unless you use the help of tools like SWAT, you basically are staring at a huge and complicated looking smb.conf in /etc/samba. I’ve been messing with Samba for many years, and I still learn a bunch every time I mess with it. I was talking to an IRC friend earlier and Samba came up as he wanted to make his shares useable to Windows, readable to everyone, but writable only to logged in users. In the past, because of my poor understanding of Samba, I always got frustrated and just made it completely open and writable by the world. To accomplish this, I even had to make the entire folder structure open to everyone, by setting the permissions to 777 (readable, writable, and executable by EVERYONE!). After our conversation I figured now is as good as any time to learn how to implement at least a little bit of security, as what he wanted to do makes complete and total sense. So after doing some Google-ing, I figured it out!

First, some prerequisites:

  1. I recommend setting all of your sub directories to be mapped to a user and group of a non-privileged user and a user that is not a human. In my case, I ran chmod to my entire file server (a little bit over 1TB of bad permissions worth) so that everything is owned by the user ftp, and the group ftp. I will show the command later.
  2. Every user you want to have write access to the folders must be a member of the same group that you set the file permissions to. I use the group “ftp” to accomplish this. All the files however, do not have to be owned by the user “ftp”.
  3. I decided to have one directory that is still available to everyone for writing called “Inbox”. That way I can open it up via sftp or what have you for any convenience reasons.
  4. Understand Windows behavior. If you map a drive as a user, even if you disconnect, Windows will still authenticate as that user even without re-mapping the drive. I am still trying to figure out how to remove those cached credentials. In the mean time, for testing I used a second “virgin” Windows machine, one that has never logged in as a Samba user so I can make sure my one public folder is writable and test different configurations.
  5. When logging into the share with Windows (e.x. mapped drive), use: serverhostname\username and then the password as normal.
  6. I strongly recommend making a backup copy of the current smb.conf. You never know. I have been beating that habit into my head when it comes to configuration files. Always back it up! I will also show that later.
  7. I completely removed printer sharing from the Samba config. I personally never will share a printer from my file server for various reasons. If you do want to share a printer, don’t forget to leave the printer shares in.

The following instructions are based on sudo usage of Debian type machines (my server is Ubuntu Server 14.04). You may not need sudo. I also use vim which is just an enhanced version of vi. Any editor will do of course. Your mileage will vary, so take the following as a guide, and not as “type these in exactly”, unless you happen to have your server setup exactly the same as mine, which would be weird.

The following also assumes /mnt/data is where all of my files that I serve are. This is actually a mount point to a RAID array. Inside of that, I have a folder called Inbox.

Part 1: Setting up Users, Groups, and the File System

The first bit will be users. Following my case, I did the following to set everything to owner and group to “ftp”. Now, you may not have either, which just means you will need to create the user and group first. Of course, it doesn’t matter what you name it. The ftp user/group is usually created upon installation of an FTP server, so I just use that.

To create ftp user and group (if you don’t already have it, cat /etc/passwd will show you all of the users):

Note: You will need to change /mnt/data (that’s just my file serving location). Login is disabled with this command though, so it won’t matter too much.

To set the permissions and ownership correctly (if you have existing files), I ran the following:

Note: I always use full paths with cmod and chown if I am changing more than one object, even if I am already in the folder, because these commands are so powerful. You can easily damage beyond economic repair your entire system with these. Always use extreme caution! My personal rule is “If I use -R, I use full path”.

Setting 775 and running chown on everything allows read, write, and execute by the user ftp, and anyone in the group ftp. It only allows read and execute access to everyone else. This allows the anonymous user to read and execute, but not modify for security. Samba will be set similarly, but having it set correctly file system wise will make it secure against any Samba mis-configurations or other attacks.

Now, there if you have a lost+found folder in your path, you will need to fix it so that root owns it again, and permissions are back to normal:

Now, one thing to keep in mind, as my point #2 above stated, every user you want to have write access to these folders and files must be a member of the group you just put on them. Simply run (usermod -G group user):

The user will now have modification rights on any folder that has the ftp group on it, with write permissions set for groups (e.x. 775).

Note: If you add a system user, and your non-Ubuntu specific distribution does not have a package called “libpam-smbpass”, you will need to either install that package, or also add the user to the Samba database manually with:

(Thanks to Mr. Wiebe for pointing that out with his Debian install)

Part 2: Setting Up Samba

Setting up the configuration of course depends entirely on what you want to do exactly. For instance, I want to be able to share everything in /mnt/data for public read and execute. I also want a place for any guest or anonymous user to place new files for me to sort through later. I called this location /mnt/data/Inbox. On top of that, I want logged in users to be able to read and write /mnt/data. This way I can mount a drive as another user in Windows and modify, delete, and change things at will. I personally took the default Samba config file, made a backup copy of it, and almost wiped it clean. Sure the comments are really useful, but reading a file with a million comments is more of a pain than just searching Google for what I really need.

Make a backup!

Now, here is what mine looks like as it might be easier to understand it after seeing it all in one place. Some key entries will be explained below:

Starting from the top, these are what I feel to be the most important options to understand, and also deviate from default:

security=share – This allows Samba to use local Linux system users to control file/folder access. There other available levels of course, mostly dealing with external means of authentication.
usershare allow guests=yes – This allows non-authenticated users access to the shares defined.

Note: Everything in between is default from the original configuration file. The directives mostly handle authenticating users and logging.

[data] – The first share I define. This is the name of the folder that appears to clients.
path=/mnt/data – The path to the files for this share. Since I try to keep things simple, this is the path to everything.
available=yes – Makes this available to clients. For example, if you want to temporarily make the share unavailable, you can change it to no and keep the configuration in place.
read only=yes – Makes the share read only to everyone, except anyone in the write list, seen below.
browsable=yes – Announces the share in browse lists. This is especially important for Windows.
guest ok=yes – Allows guests to see folders and files inside the share.
guest account=nobody – Maps the guest account to “nobody”. This way guests can’t impersonate a user.
write list=@ftp – A comma separated list of users that are allowed to write to files and folders in the share. Using the @ symbol, you can specify entire groups.
create mask=0775 – The file creation permissions. This does the same as discussed in part 1 above. Change this to match how you control permissions on your file share. This is what gets applied when a logged in user creates a new file. 775 gives permission to read, write, and delete to the user and group, but not everyone.
directory mask=0775 – Same as create mask for files, but for directories.
hide unreadable=yes – I use this specifically to hide the lost+found folder, however it is also useful to hide directories that the logged in user has no access to (not even read). This can be useful for user directory lists too.
force group=ftp – Forces new files/folders to belong to the group ftp which keeps the files available as originally designed. If you omit this option, new files and folders will only be available to the primary group of the user who wrote them.

[inbox] – This is the “public” guest writable share I have defined.
There are only 4 differences from the above entry. Both “write list” and “hide unreadable” are not present. The following directives are modified:
path=/mnt/data/Inbox – The path to the share that will be available for writing to guest.
read only=no – Opens the share to be writable from anyone, including guests..

The Inbox works for guest because using the “force group=ftp” directive allows new files and folders to be created under that group, but as the “nobody” user. This is akin to running “chmod nobody:ftp” after adding the object. Because my Inbox folder is a sub folder of the data share, there is one idiosyncrasy to keep in mind with this setup. If a guest goes to \\server\inbox, they will be able to write and modify, however, if they go through \\server\data\Inbox, they will not be able to modify even though it’s really the same folder. This is because the data share itself is locked down to guests. If this is bothersome, just make sure it is not a sub folder of another further locked down share.

After editing, remember to restart the service:


A great quick reference source for configuration options can be found here: Otherwise, don’t forget to check out and And remember, just have fun and play around with all of the options to see what the results are. The best way to learn is to do.

Nov 14

Ubuntu 14.04+: Changing Login Messages

The login messages you get when you log into SSH or the console are actually a bunch of bash scripts in /etc/update-motd.d. You can modify these and customize them as you would like. For example, all of my Ubuntu servers include a line advertising, which would be fine, but I’m just a home user and that’s a pay for service, so I’m not interested. It also has a link to documentation which I also don’t need to be reminded of every time.

Here is what the default server version login looks like:

The following instructions assume you are in the directory:

To pare the long message down, I first started by moving the script that barks out the documentation link to my home directory (just in case I need it back, but it can also be deleted). You can move it wherever you want of course, but I don’t use my home directory in my servers for anything.

To remove some of the extra returns in the system information section, I edited 50-landscape-sysinfo and commented some of the echos:

(# means comment, the script will ignore those lines).

To remove the “Graph this data and manage this system at:” lines, we will need to edit instead (note, your path may very. It might also be python2.5 instead of python 2.7. use “locate” to find it for sure).

Change the following lines:


That wasn’t too bad. Now we have this upon login:

Much better, and much less screen taken up by extra crud. Of course, if you don’t care about the pretty information block, you can just move or delete the 50-landscape-sysinfo file from the directory.

Nov 14

Ubuntu 14.04+: Automatically Start a Script as a User

There are several different ways to start a script as root, in rc.d, crontab, etc. Starting a script as a user however can be just as easy in crontab:

and then add:

So, why do this? Security. In my case I had a public service that I run (an IRC bot) that refuses to run as root for good reason. The program will only run as a user to prevent any hacking attempts getting root easily. Never run public services as root.

Nov 11

Ubuntu 14.04+: ia32-libs

ia32-libs isn’t an installable package by default anymore, thankfully a kind poster over at stackoverflow posted a simple solution to get the libraries installed. This is useful if you are running an older 32bit application in a 64bit only Linux.

Note: Others on that same page say this isn’t a good idea, although they don’t clarify exactly why. So, this is your warning, works for me, may break things, your mileage may vary, etc.

Sep 01

Ubuntu 14.04: ‘no talloc stackframe’ Error

Update (12/2/14): This is still a problem in Ubuntu, however the bug has been fixed in Samba itself since version 4.1.10. The latest version in Ubuntu’s repositories for some reason is still 4.1.6, which mean the bug still exists for us.

I have been getting this error whenever I set up an Ubuntu 14.04 machine with Samba, also when I upgraded a 12.04 LTS with Samba. This apparently is a bug problem between Samba and PAM authentication. Hopefully soon a fix will come out and get this resolved, because even the work around is not good.

Basically, the work around is to run “sudo pam-auth-update” and uncheck “SMB password synchronization”. This prevents Samba from getting updated passwords from PAM and vice-versa. This also prevents Samba from getting new passwords/accounts. If you have an existing Samba server, don’t upgrade until this problem has been resolved.

To add a user to Samba, use:

See the reported bug at:

Sep 01

XenServer 6: Adding a New Ubuntu 14.04 Template

Currently XenServer does not have a template for the new Ubuntu 14.04. This will most likely be fixed in a future update, but for now it’s a really easy to add a new template. Thanks to for the quick instructions.

In XenCenter, head over to the console of the server and log in.

Run the following 3 commands (I chose to name it the full name Trusty Tahir instead of just Trusty):

These three commands basically just copy the template from Lucid Lunx 10.04 and renames it. Simples!

Sep 01

XenServer 6: Problems Starting a New Ubuntu 14.04 VM

Currently XenServer has a problem starting a new Ubuntu 14.04 image. There is a problem with one of the Python scripts it uses to start machines. This should be fixed by an update soon, but for now it’s a really easy fix to perform real quick. Thanks to for the quick instructions.

In XenCenter, head over to the console of the server and log in.

Edit the file in question to fix the line:

In vi, head down to line 428. You can do this quickly by typing “:428″ and pressing enter. Then press “i” or the insert key to start editing.

Change this line:

to say:

Save and quit (Press ESC and type “:wq”), and you’re done. The Ubuntu 14.04 machine should now start.

Sep 01

Ubuntu: Auto Login Securely From Windows

I log into my various home Linux servers a lot (I know, geek, right?), so being able to auto log in to the servers helps a lot. Having a weak password or trying to disable password logins entirely is dangerous and insecure. After just a little setup, you can easily do it safely.

This assumes you are using SSH. If you are using Telnet to remotely manage your server, stop now and uninstall Telnet. Telnet sends all of your data, including password in plain text.

Most of these instructions were taken from:, however I do deviate a little bit as I keep the key bits at 2048. I also don’t have all of the pretty screenshots.

At a certain point you will be asked to make a passphrase (password) for your private key. You can choose not to, however that means anyone can use the keys if they get a hold of them. If you do use a passphrase which is way more secure, when you log in, you will still have to enter a password. There is another program that can be used to store and use the password automatically however on the Windows side called Pageant. Since I’m in a private network with not a lot of outside access, I do it without. I like to live dangerously.

Set up:

  1. Download PuTTY and PuTTYGen (Pageant too if you want to use a passphrase with your key).
  2. Create a profile with the server IP Address, make sure to choose SSH as the protocol. Also in Connection -> Data, specify the user to auto log in as.
  3. Be sure to save the profile after changes are made, it doesn’t do it automatically!
  4. Connect to the server. If it is the first time, it will ask to accept the server’s host key. Press Yes.

Key generation:
Windows Side:

  1. Open PuTTYGen
  2. Click “Generate” to generate a key. Move the mouse around the blank area to make it really random.
  3. After generation, it provides a few more fields. You can change the comment if you would like. Since I’m the only one who uses my personal network, I kept everything default.
  4. Create the passphrase if you have chosen to go that route.
  5. Click on “Save private key” and “Save public key”, and save them both somewhere safe and where PuTTY can get to them. The public key must end in .txt and the private key must end in .ppk.

For example, I created a folder called “Keys” in my c:\users\username directory and save them both there.
Highlight and copy the entire key (remember to scroll down/drag down if needed). You can also open the text file and copy from there.

Linux side:
In your home directory (~), create a .ssh directory and change permissions to secure the directory:

Now create a new file to paste your public key in, then change permissions to secure the key:

Note: The file should look similar to below, one line only (just wrapped):

Quick vi how-to:

Press i (or insert key) to start insert mode.
Right click in the PuTTY window to paste.
Press ESC key to exit insert mode.
Press : (colon) to enter command mode.
Type wg to both write and quit.

Back to Windows:

  1. Close out your putty session (running “exit” in Ubuntu will close your session on the server and exit PuTTY).
  2. Re-launch PuTTY and load the profile made earlier, but don’t connect.
  3. Go over to Connection -> SSH -> Auth and browse for your private key.
  4. Remember to go back to “Session” and click Save!
  5. Now click Open and you should log in automatically!

If you decided to use a pass phrase, you can use Pageant (part of the PuTTY suite) to provide the passphrase automatically. Pageant runs in the tray and waits to enter the passphrase when requested. For setup, just open Pageant and click “Add Key”. Browse to the same private key and enter the passphrase.

Sep 01

XenServer 6: An Easy Way to Apply Patches Manually

If you are setting up XenServer for the first time, or you have had an installation for a while but need to update it and aren’t paying for a license, you can’t apply updates via a pretty GUI in XenCenter. You can however do it manually in the command line.

1. Put the server into Maintenance Mode. This will require Pausing/Shutting down all of the VM’s. This way nothing gets corrupted or messed up by any chance.

2. Take a look at the system alerts that’s telling you what updates are missing. Thankfully for each patch you click on you can click on the “Go to Web Page…” button to go directly to the download. These patches are pretty big so it might take some time to get them all downloaded.

Note: As of this writing I am doing a brand new installation of XenServer, and I ended up needing 16 updates. That sounds like a lot, but one of them is Service Pack 1, which is a roll-up and takes care of a good chunk of those. Look for a service pack update first, something like “XS62ESP1″. Download that one first and apply it before downloading the rest. After that service pack, I only needed to download 7 more (which really ended up only being 5, see note below).

Note 2: In my case, even after XS62ESP1, It said I had 2 pre-SP1 updates to install, 14 and 15. I tried to install these afterwards but they would not work. After applying the rest of the post-SP1 updates however, the need for the pre-SP1 14 and 15 patches went away.

3. Download the update in question, and unzip it. You will need to upload the file ending in .xsupdate. The other files in the zip can be ignored.

4. Use a program like Filezilla to create an sftp connection to your server. You will log in as root and your password. Upload the file, it will upload to your home directory.

5. Switch over to the console tab on the XenServer itself in XenCenter. You should be logged in as root and at your home directory (~).

6. Run this command to add the update to the pool:
xe patch-upload file-name=nameofupdate.xsupdate
For example: xe patch-upload file-name=XS62ESP1.xsupdate

7. Hightlight and copy (right-click) the resulting UUID. You will need this next.
Example: 0850b186-4d47-11e3-a720-001b2151a503

8. (Optional) You can run the following to see if the patch actually uploaded:
xe patch-list

9. Run the patch to actually apply:
xe patch-pool-apply uuid=(previous ssid)
Example: xe patch-pool-apply uuid=0850b186-4d47-11e3-a720-001b2151a503

10. After it applies successfully, it just drops back down to a command line. Use XenCenter to reboot the server for the patch to take effect.

Done! Soon you will be an expert and these steps will fly by! You can remove the .xsupdate files afterwards to free up space.

Jan 01

Bored? Stats!

Every year that you are signed up with Jetpack (with WordPress), you get a report at the end of the year with several interesting (to me) statistics about your site. Because of the various server hackings that went on in the year 2012, the last report didn’t go so well, this one however worked great! Anyway, if you are really bored and looking for something to do, check it out below! It’s all pretty and everything.

Jetpack Annual Report – 2013

Anyway, happy new year!

Older posts «