Making a NAS with the Raspberry Pi & samba
I recently got my Raspberry Pi from farnell, and decided to use it to build a NAS. My laptop harddrive is fairly small (60GiB), and hence I really needed a nice backup solution that didn’t consist of an army of USB drives with easily-lost USB cables of varying sizes and shapes. Additionally, I have some windows clients in my network, which also need a good backup solutions for things like word documents, et cetera. All code and configuration files for this projects can be found in this github repository
I chose to go with a WD Elements 2TB harddisk. In principle, any harddisk should work with the raspberry pi, but I chose this one because it was affordable, large enough for my needs, comes with an external power supply, and can be connected to the raspberry pi using USB2.0. If you want to use an external harddisk without external power supply, make sure to put a powered USB hub between the harddisk and the raspberry pi.
I tried several solutions, such as FTP and WebDAV before settling on SMB. SMB however, seems to be the only thing that doesn’t make the Windows XP machines flip out. FTP has no integration from Windows whatsoever, so opening files without copying them over is impossible. WebDAV had this feature, but only with a number of programs (like Microsoft Word) which seemed to have WebDAV support baked-in at the application-level. It very much felt like a second-class citizen, and made the entire system hang in an unusable state for half a minute at times. SMB seems to be supported through some virtual file system layer, and works smoothly with all applications.
The go-to SMB server for linux is samba, which is also available from the raspian repositories. Setting up samba is extremely easy, and the default configuration hardly needs any changes. I’ve added one system user for each user that was supposed to have access, and set their logins to a little script denying them login with an informative error message.
Other clients (linux, OSX, …) can access the NAS using other protocols, such as FTP and SSH, if they want to.
In addition to the hardware mentioned above, I connected a few LEDs to the GPIO pins of the rbpi, in order to indicate various statuses.
- The top LED labeled “PWR” is connected to the 5V rail, so it’s always on as long as the raspberry pi has power.
- The middle LED labeled “RDY” is connected to GPIO port 21, and is turned on when samba has started up.
- The lower LED labeled “DATA” is connected to GPIO port 22, and is turned on when the network interface speed exceeds 500KiB/s in either down- or up-direction. There is a python script constantly monitoring the network speed using `dstat`, the source of which can be found in the github repo.
The RDY LED is simply activated and deactivated through a small init-script which has samba as dependency. In both cases, I control the GPIO ports with the suid `gpio` command from Gordons WiringPi library.
I reformatted the harddrive with ext4 (which took a whole of 10 seconds), and it seemed to work fine on my laptop. However, from the raspberry pi, mounting it would take up to 2 minutes. During this time, “mount” would eat up 100% of the CPU. I have not yet investigated why this happens, but it’s not too much of an issue for my case, as it only delays the NAS startup by a minute or two. It’d be nice to figure out, though. If it can be fixed, the boot-time for the raspberry-NAS would go from roughly 2 minutes 40 seconds down to 40 seconds.
To prevent the windows users from turning my beautiful NAS into a virus breeder, I decided to install ClamAV on it, and have it scan through all of the home directories every once in a while. ClamAV seems to be the only antivirus software that can be feasibly run on linux for ARM, all other antivirus solutions either only support x86 or amd64, or are specifically made for android.
ClamAV is entirely controlled by cronjobs, both to update the database as well as to trigger the actual scanning. I’ve created a small shellscript that scans the users home directory, and if it finds any suspicious files, sends a mail to the user.
ClamAV is quite resource-hungry, and when it starts up (which takes roughly 10 seconds), it basically consumes all the RAM of the raspberry pi immediately. To my surprise, however, it seems that this is more of a constant-overhead, and it does not start swapping or eating unsurmountable amounts of CPU time, even when it has to scan fairly large directory trees. With my current home-folder, which has a content of roughly 40 000 files and a size of 93 GiB, it needs roughly 2-3 hours to complete the scan. The script to send the email can be found in the github repo. The script is started once a week at night, and automatically turns the “RDY” LED off until it’s finished running (although you can still use it with reduced performance during the scan, of course.)
Additionally, I created a little web-interface that would display a rough status overview, see screenshot below. The python script generating this interface is in the github repo as well.
Network speed and CPU usage
So how fast does it go? The raspberry pi has only 100MBit ethernet, so we’re capped out at a theoretical 11.9MiB/s anyway. In practice, in my 100MBit/s network with one hop between my laptop and the raspberry pi, using samba and gvfsd-smb to transfer files, I get rates of up to 5.6-6.0MiB/s and rates around 5.2-5.4MiB/s seem to be the average. Perfectly fine for my purposes, but it obviously can’t keep up with direct USB2.0, USB3.0 or eSATA connected harddrives. As my laptop harddrive is only 60GiB, I’m not probable to ever wanting to backup more than 30GiB at a time on my NAS, which would take roughly 1.6-1.7 hours. If I ever happen to fill up my entire harddrive, and then want to take a backup, I’ll have to wait ~3.3-3.4 hours. I did not do any overclocking, and I doubt that overclocking will be of much help in any case, as the raspberry pi hums along at 70% CPU usage at full transfer speed anyway. If you’re doing a lot of simultaneous transfers, or you use encryption or other mechanisms that are more CPU-heavy, overclocking might help your throughput.
As you can see, the case I made for the raspberry pi is not exactly professional. Maybe I’ll 3D-print out a better one at some point in the future, however, this one seems to work well enough; it has a few openings for air to circulate. The SMSC chip gets the hottest, and transferring files at full-speed with samba gets it up to ~62-64°C. The SoC doesn’t get quite as hot, at 53-55°C. The heat exhausted is, in general, capped to 3.5W, so it’s not really particularly worrysome — I have other appliances that create way more heat.
Things I’d like to do or that are missing
- I’d like to investigate a bit on harddisk usage and possibly reduce it, on order to extend the lifetime of the harddisk and the SD-card. I think the SD card could possibly be mounted read-only entirely. Unfortunately, iotop does not seem to work on ARM.
- Use S.M.A.R.T to monitor harddisk health.
- Use hdparm/sdparm and the likes to fine-tune spindown times et cetera
The only thing that I’m really missing right now is dropbox support for ARM. It’d be nice to run a dropboxd on the raspberry pi to create an additional dropbox endpoint for backupping. You can vote here for them to add ARM support.
Using the raspberry pi as NAS works nicely, if you’re okay with 5-6MiB/s throughput speeds. It’s cheaper than most commerically available NAS options, and you can run whatever you like on it, from a HTTP server to a torrent client. Streaming HD video directly from it works fine, even with several other transfers running simultaneously. Finally a place where I can store my excess of Dr. Who and MLP pictures, fanfics and image-macros!