So you like the idea of Dropbox but don’t like the idea of your files, pictures, videos and other private data sitting on someone else’s iron? That’s the boat I was in recently when I began looking for a way to synchronize my files between my (several) PC’s and (several) smartphones. Long story short, after trying a handful of products on the market I landed firmly on Seafile. It’s easily the most robust self-hosted file-sharing server available at the time of this writing. It uses the same version control technology that makes github the beast it is. Best of all, it’s open source, so I can trust that my private media stays free from the meddling of PRISM.
For my setup I’m running a headless Ubuntu 12.04 server. The hardware is basic, and irrelevant for the purposes of this article. I’m using a free DynDns account/address for remote connectivity to my server because, frankly, I don’t want to pay for a static IP address.
I’m using a home router running DD-WRT because it can be configured for NAT reflection (a.k.a. NAT loopback) which, as you’ll see later, can potentially be important to you.
Feel free to use the default ports on install, or use custom ports if your network schema necessitates it. The rest of this article assumes you chose the default ports.
Next, go to a client PC and install the Seafile client software. On first run the software will ask where you’d like to create a Seafile directory. Now, on your client PC you should be able to navigate via web browser to the address of your Seafile server, port 8000.
OK, now here’s a tricky part that often gets overlooked. After Seafile server is installed and seemingly ready to roll out, you need to edit your ccnet.conf file on the server. On Ubuntu 12.04 it’ll be located at /opt/seafile/ccnet/ccnet.conf. Open the file in your favorite text editor and change the SERVICE_URL. What you change it to depends on how you’re going to use Seafile! If you’re going to use Seafile stricly for internal use, that is to say strictly within the same LAN as the server, then the SERVICE_URL can be a non-routable IP address (i.e. 192.168.1.2:8000). If you’re going to use Seafile on devices that are outside your LAN, then the SERVICE_URL must be a routable IP address or FQDN (i.e. myname.dyndns.org:8000)
A common problem you may run into is this: let’s say you used a routable IP address (myname.dyndns.org:8000) for the SERVICE_URL, and now you’re on a client PC that’s on the same LAN as the Seafile server. You navigate to the server (192.168.1.2:8000) in a web browser and try to download a library. Only, you can’t download it. It just sits there saying “connecting server…” and never makes progress. Well, that’s because the SERVICE_URL doesn’t match the address in your browser. They have to match.
This is where NAT reflection on your router is necessary. Most good routers will do NAT reflection automatically, others can be configured for it. However, cheap routers that are often used in homes will not support NAT reflection.
Given the above example, if you then navigate via web browser to myname.dyndns.org:8000 and you are unable to connect to the server, it’s because your router is not set for NAT reflection. Basically, you’re trying to access your router’s WAN port via its LAN port and that’s something cheap routers don’t handle well, if at all. This was the very situation in which I found myself. My resolution was to flash the firmware on my router to DD-WRT. That’s something you may or may not be in a position to pursue.
The reason I needed to use a routable IP address for my SERVICE_URL is because I have devices that sometimes need to connect to the Seafile server via the LAN and other times via the WAN. NAT reflection at the router, of course, was necessary.
I’m currently using Seafile on 3 PC’s and 2 Android smartphones. I can say it was definitely worth my time configuring the server and I know it’ll become even more instrumental in my family and work environments in the future.