Saturday, October 27, 2012

Installing Couch Potato v2

Ok, here are some basic instructions for installing Couch Potato v2 on Open Media Vault, although they'll probably work for most Debian-based distributions.

Step 1. Download the source code

First, let's create a directory for couchpotato to go.  As with the other pieces of software, I'm going to install it to the /opt directory, but you can put it wherever you want;

sudo mkdir /opt/couchpotato

If you don't already have git installed, then you'll need to install it;

sudo apt-get install git-core

Now download the python code; sudo git clone couchpotato/

Step 2. Create a dedicated user for running Couch Potato

For security reasons, it's nice to run Couch Potato under a dedicated user.  So let's create one;

sudo useradd couchpotato
sudo usermod -d /opt/couchpotato couchpotato
sudo chown -R couchpotato:users /opt/couchpotato

This will create a new user called couchpotato, assign the user to the directory /opt/couchpotato

Step 3. Test Run

We should now be able to do a little test run to see if it is working;

sudo -u couchpotato python /opt/couchpotato/

Now point your browser to the address http://<<yourserver>>:5050

If everything has gone ok, it should be working nicely.  Feel free to play around, make sure everything is working and set things up.  Then when you are ready, shutdown Couch Potato and move to the next step.

Step 4. Configure Couch Potato to start automatically

Couch Potato already has some example startup scripts that we can use.  The ubuntu version will do the trick, so copy it to the init.d directory;

sudo cp /opt/couchpotato/init/ubuntu /etc/init.d/couchpotato

Edit the settings;

sudo nano /etc/init.d/couchpotato

Make sure you set the APP_PATH to where you've got Couch Potato running (/opt/couchpotato in our case), and the RUN_AS to the dedicated user we've created (ie, couchpotato).

Now, wake it executable;

sudo chmod +x /etc/init.d/couchpotato

And as a final step, we need to set the script to be run on startup and shutdown;

sudo update-rc.d couchpotato defaults

By now, Couch Potato should run on startup.  But to start manually, you can run it directly;

sudo ./etc/init.d/couchpotato start

Addendum. Taking Care of Dependencies

This guide assumes you've already done through the steps to install SABnzbd which should mean that any dependencies have probably already been resolved.  If not, you may need to install python;

sudo apt-get install python

Sunday, October 7, 2012

Tweaking Samba Shares for XBMC

If you are like me, you're setting up your OMV server as a means of serving XBMC or something similar. However, in addition to feeding movies and music to my XBMC media player, I also like to browse my media collection via windows explorer (or the Finder on a Mac). The problem is that a lot of media players collect various supplementary files, like *.nfo files or *.jpg files for folder art. When browsing via samba, these tend to "mess" things up. I did a bit of research into samba to see if there was a neat way to configure things nicely.

The "hide" and "veto" options in samba

So when configuring a samba share, it is possible to make certain files "hidden" using the "hide files" instruction. This simulates checking the "hidden" attribute in windows. For example;

hide files = /*.tbn/*.nfo/*.jpg*/*.jpeg/

Note that each file or folder type to be hidden must be separated with a backslash (/) and that you also need backslashes at the start end end. In OMV, you can put this instruction in SMB/CIFS->Settings->Extra Options, and it will apply to ALL samba shares. Alternatively, if you want to only hide certain files per share, you can find a similar place under Edit Share->Extra Options. If you aren't using OMV you can still add this configuration, just place it in your smb.conf file (in /etc/samba/) either under [global] or under a specific share.


However, if you browse the samba share via a Mac, this won't work since OSX doesn't use the same approach for hiding files and doesn't have a "hidden" attribute. So as an alternative, you can use the "veto files" command. This instruction is handled in a similar way, and can placed in the same spot when configuring samba in OMV. For example;

veto files = /*.tbn/*.nfo/*.jpg*/*.jpeg/

However, instead of simply hiding your files, they are no longer shared. Now when you go to your shares, you won't see these files at all. Though, they still exist on the server.

Getting funky

The problem with this approach is that your media player needs to see these files. So vetoing them is counter-productive. What we want is to veto certain files, but only at certain times. Hrm...

A reasonably simply approach to this might be to configure things on a per-user basis. This is a little bit trickier, but still relatively easy. In OMV, we go back to configuring our shares and remove any references to either "hide" or "veto". Instead, we insert into Extra Options the following;

include = /etc/samba/smb.conf.%U

Again, this can be done either globally, or on a per-share basis. Basically, this instruction asks samba to look for additional configuration details whenever a user, %U, accesses a samba share. For example, if you have a user called Joe Smith, with a username jsmith and you want additional samba configurations specific to Joe, then create a file called /etc/samba/smb.conf.jsmith and put your instructions there. If samba cannot find a user-specific configuration file, then it ignores the include instruction. If you are using guest accounts in samba, then %U will be guest (ie, smb.conf.guest).

In OMV, the only way to add this additional configuration is to ssh to your server and create the file by hand.

Putting it together

Most users log into my media server with a guest account. So I've created a file called /etc/samba/smb.conf.guest which includes a single configuration;

veto files = / *.tbn / *.xml / *.jpg* / *.jpeg / *.png / *.nfo / .actors / metadata / Thumbs.db / extrafanart / extrathumbs / *.srr / *.sfv / *.nfo-orig /

I've then added the following include;

include = /etc/samba/smb.conf.%U

For both my Movies and TV shares, but not for any other shares.In addition, I've created a user specifically for XBMC, with the username xbmc. This user has access to all the media folders and sees all the content in these folders. As such, there is no need for a specific smb.conf.xbmc file.

Tuesday, August 14, 2012

Using ssh with OMV

The guides on this site assume that you already know how to access a shell on your OMV server.  But if not, here are some basic instructions for getting SSH up and running.

Some background

SSH is short for Secure Shell and is basically a mechanism for securely connecting to remote shell on a host computer.  You can do all sorts of funky stuff with SSH, but for the time being we are only interested in being able to get access to a bash shell on OMV.

Enable SSH

On OMV, ssh can be found under Services->SSH.  Tick the Enable box.  By default, it works via port 22 and it is probably best to leave things that way.  You can decide whether to allow root access via SSH, but generally this isn't required so leave the checkbox un-ticked.

Give User Access

Go to Access Rights Management->User and find your username.  Double click to edit the user, and you should be presented with a dialogue.  If you don't have a username set up, then you can quickly create one by hitting 'add'.  Scroll through the list of groups until you find one called ssh and check it.  You should now have SSH access.

Get an SSH client

To access OMV, you'll need an SSH client.  If your client computer is a Mac or Linux machine, ssh is typically installed by default.  So just open a terminal and type ssh <<username>>@<<server>>.  You should be prompted for a password, which is the same as your regular Linux password (ie, the password you used when you set up the user in the first place).

On Windows, you'll probably want to download and install PuTTY.

Friday, July 6, 2012

Installing SABnzbd

Here are some basic instructions for installing SABnzbd on your NAS. As with the other guides on this blog, they are specific to Open Media Vault on my HP N40L, but will probably work for any Debian-based linux distribution.

The simplest approach is probably to follow the instructions on the SABnzbd website, taking advantage of the package put together by JCFP. But I wanted to do a manual installation... partly so I can customise the install to my personal preferences, and partly so I can upgrade if/when I want, without waiting a new package. Also, it's been a learning experience.

As with other packages I've installed, I'll be installing to the directory /opt and will configure the software to run using a dedicated user (for security purposes). I'm also assuming you'll be logged into OMV with a non-root user that has sudo access.

Step 1. Take Care of Dependencies

The SABnzbd github site has a list of dependencies, both optional and mandatory. If you've already installed other python-based software, like Sick Beard, chances are you already have some of these packages installed. Not that it matters, since apt will work it all out for you.

sudo apt-get install python python-cheetah python-openssl python-yenc par2 unzip

Step 2. Download and unpack SABnzbd

Make sure you have changed directory to somewhere with write access.

cd /tmp

We'll use wget to download the package;


Now unpack it with tar;

tar xvf SABnzbd-0.7.1-src.tar.gz

We're going to install SABnzbd to the /opt directory. If it doesn't already exist, create it and then mv the extracted package there;sudo mv SABnzbd-0.7.1/ /opt/sabnzbd/Congratulations, SABnzbd is now essentially "installed". There are still a few things we'll want to do in order to get it running nicely.

Step 3. Create a dedicated user for running SABnzbd

Instead of running SABnzbd under our own username, or even worse under root, we will create a dedicated user for SABnzbd to run. There are a few reasons why this is a good idea, not the least of which is for security purposes.

sudo useradd sabnzbd
sudo usermod -d /opt/sabnzbd sabnzbd
sudo chown -R sabnzbd:sabnzbd /opt/sabnzbd

These commands add a new user, and then set the "home" directory for the user to be /opt/sabnzbd (ie, the installation directory). SABnzbd automatically uses the home directory to store any configuration files, in a hidden subdirectory called .sabnzbd (note the fullstop). There are pros and cons to having configurations kept in the same directory as the install. It will be a little bit easier when it comes to backups, since everything should be maintained in the one place. But you need to be careful not to accidentally overwrite the configuration directory when upgrading.

Lastly, the chown command changes ownership of the directory from root to our new user.

Step 4. Test SABnzbd

You'll probably want to edit the config file for SABnzbd. Most configurations can be handled through the GUI, but you may need to directly edit the config file in order to set the IP of your server before you can get this running.

nano /opt/sabnzbd/.sabnzbd
Find the setting labelled "host" and enter the IP address of your machine running SABnzbd. The default port is usually 8080, which will typically suffice. But if you like, you can change it here.

At this point, you can test your installation by trying to run it with the newly created user.

sudo -u sabnzbd /usr/bin/python

Point your favourite web browser to http://<<YourServerIP>>:8080. Check out your installation and make sure it is working. While you are looking around, go over to Config->General and find your API key. Take a note of this, because we'll need it for the next section.

Step 5. Configure SABnzbd to start automatically

Running things manually is all very well and good, but if your server restarts (or even worse, crashes) you'll want SABnzbd to startup automatically on boot. We can do this by creating a startup script. There are a number of startup scripts floating around the internet that we could use, but we'll use the one available on the SABnzbd site here. It's not very sophisticated, but should work.

sudo nano /etc/init.d/sabnzbd

Cut and paste the script into your nano session, and then edit it accordingly. Find the line;

/usr/bin/sudo -u sabuser -H /usr/local/src/SABnzbd/ -d -f /home/sabuser/.sabnzbd/sabnzbd.ini

And replace it with;

/usr/bin/sudo -u sabnzbd -H /opt/sabnzbd/ -d -f /opt/sabnzbdb/.sabnzbd/sabnzbd.ini

Also, find the line;

/usr/bin/wget -q --delete-after "http://HOSTADDRESS:PORT/sabnzbd/api?mode=shutdown&apikey=ENTERAPIKEYHERE"

And replace HOSTADDRESS, PORT and ENTERAPIKEYHERE with the values from your own system. Your script should be ready to work, now. We can test it;

sudo /etc/init.d/sabnzbd start

This should successfully start the instance of SABnzbd while;

sudo /etc/init.d/sabnzbd stop

should stop it cleanly. Assuming this all works, we just need to instruct the server to run the script on startup and shutdown.

sudo update-rc.d sabnzbd defaults

Everything should now be working nicely.


The first time I ran update-rc.d, everything worked nicely. Subsequently, I ran into some issues due to a conflict between the sabnzbd startup script and a script called openmediavault-beep. From what I can gather, these two scripts are both vying to be the last to run on startup and update-rc.d cannot determine their order of precedence. A quick inspection of the script openmediavault-beep, and it looks like this is just designed to send a beep so we could probably just nuke it. But instead, we'll try and fix this by giving update-rc.d a little more guidance.

Let's edit the sabnzbd startup script;

sudo nano /etc/init.d/sabnzbd

Now, at the top of the script, but just below the line marked #!/bin/sh place the following lines;

# Provides: sabnzbd
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Should-Start: $NetworkManager
# Should-Stop: $NetworkManager
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts instance of SABnzbd
# Description: Simple script to start/stop SABnzbd

I pinched this from the Sick Beard startup. Basically it specifies that SABnzbd should startup after the local and remote filesystems become available, and after the network starts up. This will be before openmediavault-beep. We can now try and re-run update-rc.d;

sudo update-rc.d sabnzbd defaults

And everything should now work. You can reboot your system to test it if you like.