I have a Synology DiskStation that I use for a home NAS. I didn't take good notes when I got it to work with Ubuntu 10.04, so I had to fumble about when I upgraded to Ubuntu 12.04 last weekend. So for next time, here is the recipe I used.

First, you need to install the cifs-utils package:

$ sudo apt-get install cifs-utils

Next, I added the following text to my /etc/fstab file:

//192.168.1.2/shared /mnt/syn cifs noauto,iocharset=utf8,uid=1000,gid=1000,credentials=/home/brian/.cifspwd 0 0

Take note of the following:

• Replace //192.168.1.2/ with the IP address or hostname of your DiskStation. Likewise, /shared is just the path on the DiskStation that I wanted to mount.
• /mnt/syn is the mount point where the DiskStation will appear on our local filesystem.
• I didn't want my laptop to mount the DiskStation on bootup, so I used the noauto parameter.
• The uid and gid should match the user and group IDs of your Ubuntu user. You can find this by grepping your username in /etc/passwd.
• The credentials parameter should point to a file you create that contains the username and password of the DiskStation user you want to impersonate (see below).

Your .cifspwd file should look like the following:

username=username
password=password

Obviously you'll want to use the real username / password pair of a user on your DiskStation.

To be paranoid, you should make the file owned by root and readable only by root. Do this after you get everything working:

$ sudo chown root:root .cifspwd
$ sudo chmod 0600 .cifspwd

I created the mount point for the DiskStation with:

$ sudo mkdir -p /mnt/syn

Then, whenever I want to use the DiskStation I use:

$ sudo mount /mnt/syn

And to unmount it:

$ sudo umount /mnt/syn

You can avoid the mount and umount commands if you remove the noauto parameter from the /etc/fstab entry. In that case, Ubuntu will automatically try to mount the DiskStation at startup.

Something strange happened that I wish to document in case it helps others. I had to reboot my Ubuntu server while troubleshooting a disk problem. After the reboot, I began receiving internal server errors whenever someone tried to view a certain forum thread on my Django powered website. After some detective work, I determined it was because a user that had posted in the thread had an avatar image whose filename contained non-ASCII characters. The image file had been there for months, and I still cannot explain why it just suddenly started happening.

The traceback I was getting ended with something like this:

File "/django/core/files/storage.py", line 159, in _open
return File(open(self.path(name), mode))

UnicodeEncodeError: 'ascii' codec can't encode characters in position 72-79: ordinal not in range(128)

So it appeared that the open() call was triggering the error. This led me on a twisty Google search which had many dead ends. Eventually I found a suitable explanation. Apparently, Linux filesystems don't enforce a particular Unicode encoding for filenames. Linux applications must decide how to interpret filenames all on their own. The Python OS library (on Linux) uses environment variables to determine what locale you are in, and this chooses the encoding for filenames. If these environment variables are not set, Python falls back to ASCII (by default), and hence the source of my UnicodeEncodeError.

So how do you tell a Python instance that is running under Apache / mod_wsgi about these environment variables? It turns out the answer is in the Django documentation, albeit in the mod_python integration section.

So, to fix the issue, I added the following lines to my /etc/apache2/envvars file:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Note that you must cold stop and re-start Apache for these changes to take effect. I got tripped up at first because I did an apache2ctrl graceful, and that was not sufficient to create a new environment.