bookmark_borderNo networking in Docker containers under Debian 10

I finally started to migrate the first few servers to Debian 10, codename „Buster“. With the last upgrades I never stumbled upon any issues. However, this time we see a problem when using Docker as the containers are unable to communicate to the internet.

Upgrade to Debian 10 reliable as always

As usually, the upgrade process went through very smoothly. Something I really love Debian for. Fast, simple and reliable upgrade processes are basically things you always want to see on a server. Sadly, Debian itself doesn’t provide a Docker package in their repositories. This means you have to install it from a third party repository. In this case this repository comes from the official Docker developers. But with a third party repository enabled, we have to expect possible hassles when it comes to upgrading.

No networking connection within containers

If you upgrade your Debian 9 machine to Debian 10 and you’re using Docker, you will not be able to use get the network running within any container. This is due to the heavy dependency of Docker to IPTables.

With Debian 10, nftables is the new standard for package filtering in Debian. This is also mentioned in the offical Debian Wiki. However, it seems like that Docker isn’t ready for nftables at the current date (of writing this).

Workaround: Fallback to the „old iptables way“

Luckily, there is already a workaround available. People who are upgrading to Debian 10 and aren’t using nftables already can simply force Debian to switch back to IPTables again as the user arkodog figured this out on the moby GitHub:

user@debian:~$ sudo update-alternatives --config iptables
There are 2 choices for the alternative iptables (providing /usr/sbin/iptables).

Selection Path Priority Status
* 0 /usr/sbin/iptables-nft 20 auto mode
1 /usr/sbin/iptables-legacy 10 manual mode
2 /usr/sbin/iptables-nft 20 manual mode

Press <enter> to keep the current choice[*], or type selection number:

In this case you have to choose number 1 because it’s the desired „iptables-legacy“ which we need to get the networking with Docker working again. Press enter and reboot your machine.

Will Docker support nftables in the future?

There is a lot of talking going on about this topic. Right now, Docker doesn’t support nftables but it seems like the support will come sooner or later. So long, we have to live with the workaround in using IPTables instead. An alternative however would be to use the –iptables=false switch. But this would mean you would have to write all the rules normally automatically created by Docker with nftables in your own.

Further links

bookmark_borderSetup SeaFile with OnlyOffice on one Docker host

A self hosted cloud is something which is interesting for a lot of people nowadays. Whether it be that they don’t like to share their data with a big company or for learning effects just to name a few reasons.
In this article we take a look at SeaFile which is a open source cloud software solution. To get a more modern touch, we will also integrate OnlyOffice into SeaFile. This will allow us to do collaboration office document editing, including docx, pptx and xlsx files (Microsoft Office). Don’t be afraid because of the length of this article. If you’re already more familiar with techniques like SeaFile, Docker and OnlyOffice you can easily skip to the chapters where it start to be interesting for you.

Why SeaFile and not NextCloud?

I’ve decided to go with SeaFile instead of NextCloud about a year ago. The simple reason was speed! SeaFile is amazingly fast in synchronization. Even if you have thousands of little files, they all will be synced fast.
Another big reason to go with SeaFile is delta synchronization. Delta synchronization basically means that SeaFile is able to determine which part of your file has beed changed and is then only uploading the changed part of this file. This mechanism comes hand in hand with the overall synchronization speed, too. SeaFile does also offer end-to-end encryption. This means you can encrypt your files locally and upload them to the server. This makes the files unreadable for third parties.
If you want to extend your Cloud with things like contact and calendar synchronization, then NextCloud might be the better choice for you as there is no option to integrate such things in SeaFile. SeaFile is a pure cloud solution for files, but it is doing this one key feature almost perfect.


First of all, I assume that you have already Docker installed on your server system. If not, check out the manual from Docker here: official Docker installation instructions. Your (server) system should have at least 4GB of RAM and 5 GB of free hard disk space in order to install the needed container files. In addition to these 5 GB you need the desired amount of free hard disk space for your files to be stored.
If you don’t have a server or system at home which you can use, you can try a hosted server at one of the many providers out there. I can recommend Netcup as a provider. You can find their offers here: netcup VPS. You can also use one of the following codes at the checkout. These codes are 5€ vouchers for new customers at netcup:

  • 36nc15574364944
  • 36nc15574364943
  • 36nc15574364942
  • 36nc15574364941
  • 36nc15574364940

Hint: These vouchers are part of a affiliate system which means a get a small portion as a reward.

Create a Docker network

The first step we do is to create a Docker network interface. We need a extra interface in order to assign static private IP addresses to the containers. Why we need static IP addresses anyway? This will be explained later on in this how to.
The following command creates a new Docker network interface which will be named „cloud“ with a maximum of 253 usable IP addresses:

user@server:~$ sudo docker network create --subnet= cloud

The IP addresses within this network are going from to The first address is being used by the Docker host itself (in this example We could cut down the usable addresses even more but for easiness, let’s stick with this solution right now.

Setup the SeaFile Docker container

Now that we have created a dedicated Docker network we can start to create the SeaFile Docker container. In order to store the database as well as the client files on the Docker host, we have to create a folder which we then mount in the container. In this example I’ve decided to store all the SeaFile related files on /srv/seafile on the host system. So we have to create this directory first:

user@server:~$ sudo mkdir /srv/seafile

As next we can finally create the Docker container. The following command creates a SeaFile Docker container with the latest version available detached (-d switch). The rest of the parameters are explained below:

user@server:~$ sudo docker run -d --name seafile --net cloud --ip -e SEAFILE_SERVER_LETSENCRYPT=true -e -e -e SEAFILE_ADMIN_PASSWORD='MyPW' -v /srv/seafile:/shared -p 80:80 -p 443:443 seafileltd/seafile:latest
The parameters in detail
  • –name: The name of the container. In this example the container will be called seafile.
  • –net: The network were the container will be attached to. We use the previously created cloud network here.
  • –ip: The fixed IP address within the cloud network.
  • -e SEAFILE_SERVER_LETSENCRYPT: This is a parameter which will be bypassed to the containers setup script (which runs the first time when you create a new container). It tells the container that SSL encryption (HTTPS) will be enabled and we want to get a free certificate from Let’s Encrypt. Keep in mind that the DNS resolution must work in order to get a valid Let’s Encrypt certificate! This certificate will be valid 90 days. To extend it, simply recreate the container (look at the section Extend Let’s Encrypt certificate below to find out more).
  • -e SEAFILE_SERVER_HOSTNAME: Also a parameter which is bypassed to the setup script. Sets the actual wanted hostname within the SeaFile Docker container.
  • -e SEAFILE_ADMIN_EMAIL: Another setup parameter. Sets the the mail address of the SeaFile administrator. This will also be the login for you when the container is up and running.
  • -e SEAFILE_ADMIN_PASSWORD: The password of the SeaFile administrator.
  • -v /srv/seafile:/shared: We mount the previously created directory /srv/seafile on the host system in /shared within the Docker container. If we wouldn’t mount /shared, all files would be gone after restarting or recreating the SeaFile container.
  • -p 80:80 and -p 443:443: We make the SeaFile container accessible from the world wide web over Port 443 and 80 which are the standard ports for HTTP and HTTPS. However, all unencrypted HTTP traffic will be automatically redirect to the encrypted way over Port 443 (HTTPS).
  • seafileltd/seafile:latest: This downloads the latest version of the SeaFile server from the official Docker Hub. Docker Hub is basically the package manager of Docker.

Don’t forget to adjust the parameters according to your needs. After a few minutes, your SeaFile installation will be ready to use. You can access it with your public domain or IP address, for e.g.

Setup the OnlyOffice Docker container

Now that SeaFile is running and accessible, we can make OnlyOffice ready for usage, too. As already stated, OnlyOffice is a editor for most of the Microsoft Office document formats including docx, pptx and xlsx. It’s open source and free to use. Before we start, we will create a directory where OnlyOffice can store it’s cache and other database related files. We will later mount that directory within the OnlyOffice Docker container just like we did with SeaFile:

user@server:~$ sudo mkdir /srv/onlyoffice
Install certbot and obtain a Let’s encrypt certificate

We’ve already secured SeaFile with the help of a Let’s encrypt certificate. Thus it’s just consequent to secure OnlyOffice with Let’s Encrypt as well. To do so we need a little tool which is called certbot. It does all the work for us. If you’re running a Ubuntu server version 18.04 or higher, you can easily install it like this:

user@server:~$ sudo apt install certbot

If you’re a Debian user, you have to use Backports in Debian 9 in order to install certbot. To enable backports in Debian 9, create a new file under the directory /etc/apt/sources.list.d/ named backports.list with the following content:

deb stretch-backports main contrib non-free

Save and close the file. Now we can install certbot as well:

user@server:~$ sudo apt update && sudo apt install -t stretch-backports certbot

Now that we have certbot installed, we can get another certificate. Warning: Don’t use the same domain name which you already used in SeaFile here! Otherwise your SeaFile certificate will be invalidated. The easiest way is to use another subdomain like

user@server:~$ certbot certonly --standalone -d

Just like with SeaFile, ensure that the subdomain you’re using is pointing to the public IP address of your server. Otherwise you won’t get a certificate and certbot will return an error. If the process was successful, the certificate will be valid 90 days and you can find it under /etc/letsencrypt/live/
These files have to be copied so that the OnlyOffice container is later able to read them. We also have to extended the certificate with the Let’s Encryt chain. Otherwise SeaFile will not be able to validate the certificate later on which results in errors when opening documents with OnlyOffice:

user@server:~$ sudo cp /etc/letsencrypt/live/ /mnt/onlyoffice/data/certs/onlyoffice.crt
user@server:~$ sudo cp /etc/letsencrypt/live/ /mnt/onlyoffice/data/certs/onlyoffice.key
user@server:~$ wget
user@server:~$ sudo sh -c "cat lets-encrypt-x3-cross-signed.pem.txt >> /mnt/onlyoffice/data/certs/onlyoffice.crt"
user@server:~$ rm lets-encrypt-x3-cross-signed.pem.txt
Setup OnlyOffice

We’re now finally able to start OnlyOffice. For this use the following command (the parameters are explained below again):

user@server:~$ sudo docker run -i -t -d -p 8443:443 --name onlyoffice --net cloud --ip --add-host -v /srv/onlyoffice/logs:/var/log/onlyoffice -v /srv/onlyoffice/data:/var/www/onlyoffice/Data onlyoffice/documentserver:latest
The parameters in detail
  • -p 8443:443: We make OnlyOffice accessible over port 8443 from connections over the world wide web. You don’t have to use the port 8443 but a higher, more uncommon port is recommended. It’s something like a additional „security factor“. Higher, more unusual port numbers are more likely not be considered by bots.
  • –net and –ip: Again we use the dedicated cloud Docker network and set a fixed IP address.
  • –add-host: This is a key parameter here. We are using OnlyOffice and SeaFile on a single host system. This means that OnlyOffice has to be able to contact SeaFile over port 9000. By default, that’s not possible. As a workaround (which is also more secure than allow SeaFile to communicate over port 9000 with the world wide web) we use this parameter to add an entry to the /etc/hosts file on the OnlyOffice container. This entry is pointing to the internal Docker IP address.
  • -v: Same as with the creation of the SeaFile container. Files like logs will be stored there. This also contains the certificates we’ve created the step before.
  • onlyoffice/documentserver:latest: Like with the SeaFile container creation, we use the latest OnlyOffice documentserver version available at the Docker Hub.

After a few minutes, the OnlyOffice instance should be ready to use. You can check this if you visit the IP address or the domain name of your instance / server. For e.g. If you see Document Server is running, you’re good to go.

Get SeaFile and OnlyOffice to work together

Now that SeaFile and OnlyOffice are running we have to link them in order to get them working together. To do so, we have to tell SeaFile how our OnlyOffice instance can be reached. So open the file /srv/seafile/seafile/conf/ on your docker host and add the following lines at the end of this file:

ONLYOFFICE_FILE_EXTENSION = ('doc', 'docx', 'ppt', 'pptx', 'xls', 'xlsx', 'odt', 'fodt', 'odp', 'fodp', 'ods', 'fods')
ONLYOFFICE_EDIT_FILE_EXTENSION = ('docx', 'pptx', 'xlsx')

You have to edit the ONLYOFFICE_APIJS_URL to the actual URL of your OnlyOffice instance. Save and close the file. Even we force SeaFile to not verify the OnlyOffice certificate (parameter VERIFY_ONLYOFFICE_CERTIFICATE = False) it does check the certificate anyways. Thus we have added the complete Let’s Encrypt chain a few steps before.
That’s already it. Restart the two containers and you should be able to create / modify documents in SeaFile:

user@docker:~$ sudo docker stop onlyoffice
user@docker:~$ sudo docker stop seafile
user@docker:~$ sudo docker start onlyoffice
user@docker:~$ sudo docker start seafile
Lack of security token support in SeaFile

Security is really important these days. While SeaFile only works if you logged yourself in, OnlyOffice has implemented another approach. The so called „security token“. A security token is used by the cloud software solution (like NextCloud or Seafile) to authenticate against the OnlyOffice instance.
While NextCloud does support this security token mechanism, sadly SeaFile doesn’t. In addition to this you can’t simply use a firewall to block all traffic from outside to your OnlyOffice instance because the client also have to able to communicate with it. Because of this I recommended (as a little bit of blurring) the usage a more uncommon port. I know that this doesn’t have something to do with making something „secure“, however it’s at least something for now. Implementing security token support is on the road map of the SeaFile developers.
For clarification, not using security tokens doesn’t mean everyone can access your files. It just means that everyone who is able to find out the actual address of your OnlyOffice instance can use your instance for editing documents as well.

Updating the containers

Updating the SeaFile as well as the OnlyOffice container is really simple. To do so, stop the container, delete it and recreate it. The already explained latest tag at the end of the image name makes sure that you always pull the latest stable version available. So for example to update Onlyoffice:

user@docker:~$ sudo docker stop onlyoffice
user@docker:~$ sudo docker rm onlyoffice
user@docker:~$ sudo docker run -i -t -d -p 8443:443 --name onlyoffice --net cloud --ip --add-host -v /srv/onlyoffice/logs:/var/log/onlyoffice -v /srv/onlyoffice/data:/var/www/onlyoffice/Data onlyoffice/documentserver:latest

Updating SeaFile does look similar:

user@docker:~$ sudo docker stop seafile
user@docker:~$ sudo docker rm seafile
user@docker:~$ sudo docker run -d --name seafile --net cloud --ip -e SEAFILE_SERVER_LETSENCRYPT=true -e -e -e SEAFILE_ADMIN_PASSWORD='MyPW' -v /srv/seafile:/shared -p 80:80 -p 443:443 seafileltd/seafile:latest

Please keep in mind that you have to modify the docker create command again so that it fits to your initially create command. In order to keep track if there are any updates available, you could write a Cronjob which does the steps above automatically (something I really wouldn’t recommend due to possibly update failures). Or you subscribe to the developers newsletter so that you get notice when a new version is released. Sadly the Docker Hub doesn’t have a functionality in sending mails when an image is being updated (as of May 2019).

Extending Let’s Encrypt certificates

Extending the validity of Let’s Encrypt certificates for SeaFile is really simple. Just recreate the container like you would update the container. SeaFile checks the certificate automatically at the recreation process and extends the validity of the certificate.
For the manually created Let’s Encrypt certificate for OnlyOffice we have to stop the SeaFile container (because this container is using the port 443 and 80 which we need for certbot). Than we simply repeat the commands like the first time we got the certificate. This includes the copy commands as well as adding the Let’s Encrypt chain, too. While renewing the certificate, certbot may asks you if you want to keep the actual certificate or if you want to replace it. This message only pops up if you’re actual certificate isn’t already expired. You can surpass this message with the –force-renew parameter:

user@docker:~$ sudo certbot certonly --force-renew --standalone -d

You can wrap these steps in a Cronjob of course as well. This would allow you to extend the certificate without even touching your system.

A few words about firewalling

If you’re using a firewall (which I highly recommend) make sure that port 80 and 443 (HTTP / HTTPS) are accessible from the world wide web. Also make sure that the port you’ve set for the OnlyOffice instance is accessible from outside (in this article this port was 8443). The client has to be able to communiate with OnlyOffice, not just the SeaFile server.

SeaFile with OnlyOffice: A great couple

As you can see, thanks to Docker making and maintaining your own, self-hosted cloud is as easy as it never was. However, if you think that it is still to difficult for you to manage such a solution and thus you want to stick to a centralized hosted solution like Dropbox, Google Drive or OneDrive, consider at least to encrypt the files you store at their servers. For your own privacy and security. Solution likes Boxcryptor (free with the basic version) or Cryptomator (open source and free to use) are making it very easy to encrypt your files at cloud providers.

Further links


bookmark_borderSteam Proton compatibility layer: The holy grail for Linux gaming?

On 21th August 2018, Valve announced that they are soon start to distribute a new compatibility layer. It’s exclusive for Linux and is called Proton. Proton can be compared to WINE but it comes with support from Valve. That means that if a game is official listed as „supported by Proton“ (the real name of the feature is Steam Link) it will work with your Linux gaming machine. This is unlike WINE where you don’t get support for games you want to play. After some days of testing and reading through opinions on the internet about this compatibilty layer, I want to make a statement how I think and feel about Proton.

About Proton

Proton is developed by Valve in cooperation with Codeweavers. Codeweavers is a long time WINE supporter and offers the software Crossover for MAC and Linux. Crossover is WINE bundled with a easy to use GUI and some additional features like guided setup. Codeweavers does support dozens of programs and games which are guaranteed to work with Crossover. Therefore it just makes sense that Valve created Proton with the help of the professionals from Codeweavers.

Why not simply use WINE?

This might be something a lot of people are questioning themselves. Why not simply use WINE? Well, Proton has some great advantages in direct comparison to WINE. In my short period of testing, I can say that selected DirectX 11 and DirectX 12 games are working with Proton while they fail to start with WINE. A popular example here is The Witcher 3. Also the integration of a wireless XBox 360 controller is flawlessly. You simply plug in your controller and use it. You don’t have to remap buttons or tell the driver to mimic as an x-pad or something get it working. But these two things are just small parts of a whole bigger picture of exciting features in direct comparison to WINE.

It really feels like a native application

Ever game I’ve tested so far (including Blood Bowl 2, Warhammer 40k Dawn of War: Soulstorm and Dead by Daylight) was simply installed like a „normal“ Steam game. Click install, wait for the download and click „Play“ afterwards. Dependencies (like DirectX or Microsofts Visual C++ Runtime) are automatically installed and prepared. This is totally different from installing every single game in a different WINE Prefix in order to install the needed DLLs clean and separated. With that being said, you could see Proton as a modified WINE which also maintains and controls each prefix on it’s own. For me, this is fantastic. I really abhorred that I had to create a new WINE prefix for every Steam game I wanted to install. I know that I could have installed all games in just one WINE prefix as well. But sometimes the different needed DLLs for each game came in each others way which resulted in a game crashing or simply being unplayable.

Performance, performance, performance …

The performance with Proton is really good keeping in mind that this is a compatibility layer. Is it better than with WINE? I would say Yes at least for the games I’ve tested so far. Is it equals to  Windows? I doubt it. But for somebody who uses WINE for a long time, I was happy to get at least up to 60% of the performance in direct comparison to Windows. With Proton however, I would say we are near 80-85% of the performance. That’s impressive and I’m excited to see the further development.

Is this the end for native ports?

This is something which came up in my mind several times. A lot of Linux enthusiasts are calling this argument as their number one reason against Proton. Is such a implementation really the end for future native game ports under Linux? In my humble opinion the following three scenarios could happen:

  1. If Microsoft doesn’t fully lock up their operating system (something Valve was afraid of when they started to work on Steam OS), Proton could be the future for a lot of Linux games, because the developers don’t want to put in that much effort in a port for the 1% of Linux users. With Proton these developers are at least „ready“ to support Linux that way.
  2. Proton is the entry point for developers to create native Linux ports in the future. Every game bought with a Linux client and played with Proton is counted as a Linux sale (according to a question from GamingOnLinux to Valve). With the increasing number of sales, developers start to provide native ports because it’s „worth it“.
  3. Proton will be terminated due to the lack of interest by the users or game developers.

If I would have to pick one of these scenarios, I would say that it’s most likely that the first one will happen. And I would be totally fine with that.

When is Proton finally released?

Proton is in the latest Steam Beta client. Everyone can participate in this beta be enabling it in the settings section of the Steam client:
Setting to enable Valve Proton
Afterwards you will be able to install and play the official supported games which are at the time of writing:

  • Beat Saber
  • Bejeweled 2 Deluxe
  • Doki Doki Literature Club!
  • DOOM
  • DOOM II: Hell on Earth
  • Fallout Shelter
  • FATE
  • Geometry Dash
  • Google Earth VR
  • Into The Breach
  • Magic: The Gathering – Duels of the Planeswalkers 2012
  • Magic: The Gathering – Duels of the Planeswalkers 2013
  • Mount & Blade
  • Mount & Blade: With Fire & Sword
  • NieR: Automata
  • PAYDAY: The Heist
  • S.T.A.L.K.E.R.: Shadow of Chernobyl
  • Star Wars: Battlefront 2
  • Tekken 7
  • The Last Remnant
  • Tropico 4
  • Ultimate Doom
  • Warhammer 40,000: Dawn of War – Dark Crusade
  • Warhammer 40,000: Dawn of War – Soulstorm

If you want to start all Windows games with Proton, you have to check the additional checkbox in the Steam settings:
Settings to enable Valve Proton for all games

What about „non-steam“ games?

I also tried to add a „non-steam“ Windows executable. In this case it was Guild Wars 2. Right now it seems like this isn’t working. Steam tries to start the Guild Wars 2 executable as a Linux executable which results in an error of course. However, Valve is providing a build instruction on their official GitHub repository. After this build is done, you should be able to use Proton on the command line just like WINE.

Is Steam Link / Streaming supported?

I’ve tested Blood Bowl 2 on Linux with Proton on a Steam Link in my local network. It worked and was handled like starting a native Linux game. I didn’t found a note in the official release statement from Valve, but it seems like Valve considered Proton to work over Steam Link / Streaming in the first place. This is great and just one more reason to feel that Valve means it serious with Proton in the future.

The Windows game XYZ runs with Proton. How to get it white listed?

Valve is actively asking users for their help with testing and reporting games. If you tested a game with Proton (that isn’t official supported right now) and it works, you can go to the GitHub repository of Proton and report a white list request under the issues section. However, there are a lot of people actually reporting bugs and white list request. Thus it can take some time until your request is processed.


Will Proton push developers to use the compatibility layer instead of providing native ports? A lot of them might actually go this route. But is this bad for Linux gaming in general? In my humble opinion: No!
I can remember of statements made by Bethesda that native Linux ports aren’t worth it (right now) and therefore they will not support it. Jon Carmack (former developer at ID software) stated similar things and recommended to improve WINE instead of native ports back in 2013. With Proton we might see games by such developers coming to Linux as well. Think about it, a company could reach an additional ~1% of the whole Steam user base with an additional time effort of round about 10 hours or so. A native port would be way more time consuming and thus expensive. Therefore they are not providing a native port but they are welcoming such a solution like Proton. You see where this is going, right? Hopefully we will see a lot of developers welcoming this solution and therefore supporting Linux. However, we will also see a lot of developers saying „Why a native port when we can use Proton?“. To be honest, I really don’t care anymore, as long as Proton is giving me a overall good to ok performance and the game runs as excepted (especially multiplayer games with anti cheat systems like „Easy Anti Cheat“ could be a obstacle here). Don’t get me wrong, I would love to see more native Linux ports. However, I simply waited too long for companies to support Linux. My patience has been reduced to a minimum now. Even companies like SI Games which are developing the Football Manager and Football Manger Touch series are dropping Linux support. With the 2019 release of Football Manager and the Touch variant they will provide no more Linux version. The reason? The low sales didn’t covered the additional dev costs.

Further links

bookmark_borderDLNA server with MiniDLNA under Linux / Raspberry Pi

DLNA is a great service. With a DLNA server you can distribute videos, music or pictures to almost every Smart TV and / or set top box like an Amazon Fire TV. With DLNA you don’t have to bother if you’re TV supports the given file format. DLNA does cover this for you. One of the DLNA services which is easy to install, configure and use is MiniDLNA. This article shows you how to setup a MiniDLNA server under Linux / Raspberry Pi with a few simple steps.

Which hardware to use?

The good thing is, that you don’t have to use an Intel / AMD based machine to stream Full HD over DLNA. Even a Raspberry Pi with an external USB hard drive attached is capable of streaming Full HD movies over a Gigabit Ethernet. If you want to build yourself a DLNA Raspberry Pi server, I would recommend the following hardware:

Whether you go with the Raspberry Pi setup or not, ensure that you have a hard drive which is big enough to store your media files. As the Linux distribution of choice I recommend you Ubuntu or Debian (this tutorial is also written for Debian and Ubuntu). If you’re going with a Raspberry Pi setup, check out Raspbian (which is a Debian made for the Raspberry Pi). To setup your Raspberry Pi with Raspbian, you can checkout the Raspberry Pi image creation tutorial from the Raspberry Pi Foundation.

Why MiniDLNA as the DLNA server software of choice?

Besides MiniDLNA there are plenty of other services available. One of the biggest solutions are MediaTomb and Twonky. Both are the opposite of MiniDLNA. They are coming with complex and more powerful configurations tools. At the same time they are way more resource hungry. MiniDLNA works with a „keep-it-simple“ method. You basically just have to install the service and tell MiniDLNA where the media files you want to stream are located at.
Besides the „keep-it-simple“ factor, MiniDLNA is also a very resource saving solution, as already mentioned. This comes hand in hand with the resources limits a Raspberry Pi is giving us. However, even if you’re going to install a MiniDLNA server on a Intel Core i7, a straight forward easy to install / use solution is always the one you should consider first in my humble opinion.

Install MiniDLNA

The Raspbian, Debian and Ubuntu package repositories are already providing a ready to go MiniDLNA package. With that being said, the following command installs the latest available MiniDLNA package onto your system:

user@raspberrypi:~$ sudo apt-get update && sudo apt-get install minidlna

Depending on your internet speed, the download and installation of the MiniDLNA package should be done within a minute or two.

Configure MiniDLNA

At this point of the tutorial I assume that your (external USB) hard drive is already formatted and filled with the media you want to share over DLNA. To give you a example which is as most as accurate as possible, I also assume that your hard drive is already mounted on your Linux machine under /mnt/usb. If your hard drive is mounted at a different location, simply replace /mnt/usb with the mount point you had chosen.
The configuration file for MiniDLNA is simple. While we could dive deeper into the configuration parameters, we want to keep it as simple as possible as well. The only two parameters which are interesting for our setup for now are media_dir and user. To set these two configuration parameters, open the configuration file with your editor of choice and go on reading this article. The configuration file is located at /etc/minidlna.conf.

Start MiniDLNA as a non-root user

By default MiniDLNA starts it process with the root user. While this makes things easier, it’s a security issue which should be fixed. To do so, scroll down in the MiniDLNA configurations file and search for the following lines:

# Specify the user name or uid to run as (root by default).
# On Debian system command line option (from /etc/default/minidlna) overrides this.

Remove the starting hash from the user line. This tells the MiniDLNA Daemon to start the process as the user minidlna. The user minidlna was already created by installing MiniDLNA two steps before.

Add media directories to MiniDLNA

MiniDLNA supports audio, picture and video files. You don’t have to store all files on one single hard disk to share them over MiniDLNA. However, you have to configure a media directory per storage. You can do this in the MiniDLNA configuration file, too:

# Path to the directory you want scanned for media files.
# This option can be specified more than once if you want multiple directories
# scanned.
# If you want to restrict a media_dir to a specific content type, you can
# prepend the directory name with a letter representing the type (A, P or V),
# followed by a comma, as so:
# * "A" for audio (eg. media_dir=A,/var/lib/minidlna/music)
# * "P" for pictures (eg. media_dir=P,/var/lib/minidlna/pictures)
# * "V" for video (eg. media_dir=V,/var/lib/minidlna/videos)
# * "PV" for pictures and video (eg. media_dir=PV,[...]

As you can see, in the standard configuration file there is already a media directory configured. However, that’s just an example and you have to change this to the actual directory where your media files are stored. As an example, a setup with three media directories could could look like this:


After you’ve added all the desired media directories, save and close the configuration file. To finally apply the changes to the MiniDLNA server, you have to restart the service:

user@server:~$ sudo systemctl restart minidlna

The first scan process could take some minutes. When you’re copying / moving additional files over time into these directories, MiniDLNA will find them automatically. Look at the webinterface if you want to know if the scanning processes is finished (go to the next chapter to find out how to access the MiniDLNA webinterface).


The MiniDLNA service comes with a small webinterface. This webinterface is just for informational purposes. You will not be able to configure anything here. However, it gives you a nice and short information screen how many files have been found by MiniDLNA. MiniDLNA comes with it’s own webserver integrated. This means that no additional webserver is needed in order to use the webinterface.
To access the webinterface, open your browser of choice and either enter the IP address or the hostname of the server / Raspberry you’re want to connect to, followed by the port 8200. For e.g.: http://raspberrypi:8200:

DLNA server - MiniDLNA status page
MiniDLNA status page

As you can see, I’m only streaming video files over my MiniDLNA setup. In the upper table you can see that my MiniDLNA Raspberry setup is ready to stream 1108 video files on demand. The Connected clients table lists the actual connected clients. In this list I see devices like my Smart TV, my Playstation and many others. Even though a lot of these clients aren’t streaming right now, they keep an active connection to the MiniDLNA server. When they start to stream some files, you will see the actual connections in the last cell of the second table.

The actual streaming process

This paragraph is just a short overview how a connection from a client to the configured and running MiniDLNA server could work. In this scenario we simply use a computer which is in the same local area network than the server. As the client software we use the Video Lan Client. Simple, robust, cross-platform and open source. After starting VLC, go to the playlist mode by pressing CTRL+L. You will now see on the left side a category which is called Local Network. Click on Universal Plug’n’Play which is under the Local Network category. You will then see a list of available DLNA service within your local network. In this list you should see your DLNA server. Navigate through the different directories for music, videos and pictures and select a file to start the streaming process:

DLNA server VLC stream
The MiniDLNA server was recognized by VLC (click to enlarge)

This is just an example of how to connect to your MiniDLNA server with a desktop client. VLC is also available for Android devices. Using MiniDLNA with VLC on an Android device even allows you to use the Chromecast to cast a music file, series of pictures or videos to your TV. However, if you have a Smart TV, most of them can connect to DLNA services directly.

Start, Stop and restart MiniDLNA

Starting, stopping or restarting the MiniDLNA service is „business-as-usual“. But just for the records, here are the commands:

user@server:~$ sudo systemctl start minidlna
user@server:~$ sudo systemctl stop minidlna
user@server:~$ sudo systemctl restart minidlna


Setting up your own DLNA server is really easy. If you use a Raspberry Pi in combination with a USB hard disk, you have a cheap but solid and flexible open source based solution. You are not forced to use a prebuild NAS appliance which maybe limits you in the maximal size of the hard disk or the file formats you want to use. Also, installing and configuring your own DLNA solution is a good learning experience. So what you’re waiting for. Start streaming your own movies, pictures and music via DLNA. And if you have any questions or you just want to let me know how your own DLNA setup looks like: Leave a message in the comments below 🙂

Further links

bookmark_borderContent servers unreachable: Steam does not download

If your Steam client gives you the error An error occurred while installing Your Game (content servers unreachable) whenever you want to update or install a game, you might have to check your network connection in the first place. However, if the error isn’t related to your network, this quick and easy workaround will help you to get rid of the error.

Who is affected by this problem?

Basically everyone can be affected by this. I for myself got confronted with this problem twice under Windows and almost every time when I’m using the Steam Windows version under Linux with WINE. Because of this fact, this article only covers Windows and Steam WINE installations. If you’re a user of the Mac or Linux native Steam client, this workaround could help as well. However, you have to find the specific file (which has to be edited later on) on your own.

Steam content servers unreachable error message
Steam yells „content servers unreachable“ in a WINE prefix

The workaround

This workaround has originally brought up by a user in the forums. We have to add a list of servers to the config.vdf file from your Steam installation. This list of servers are representing the content servers provided by Valve. Navigate to the config directory within the Steam installation directory. It is located under Windows by default in C:\Program Files (x86)\Steam\config. For a default Linux WINE prefix you have to navigate to $HOME/.wine/drive_c/Program Files (x86)/Steam/config. Search for a file called config.vdf. Open the file with the Notepad editor under Windows or with the editor you’re typically use under Linux and add the following line after the line starting with the word cip:

"CS" ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Save and close the file. If you’re a Windows user you may see a message saying that you can’t save the edited file at the given location. If so, simply save the new config.vdf file on your desktop. Move the so saved file to the Steam config directory afterwards.


I’m unable to tell you why Steam sometimes isn’t able to find the Content servers on it’s own. The list above represents the content servers provided by Valve. The list of servers could change in the future of course. But right now, the workaround gives you the capability to download and update your Steam games again.
If you know more about this issue, especially why it actually occurs on some installations, please let me know in the comment section below.

Further links