Owncloud 9.0.1 on Raspberry Pi 3 – Step by Step

Why?! I bought a Raspberry Pi 3 on the day it was announced, because I am easily excitable. When it arrived, I tried out a few things like compiling Synergy (much faster than a RPI2!) and the oblig. Quake 3. Once the fun wore off, I thought this might be a good time to finally … Continue reading “Owncloud 9.0.1 on Raspberry Pi 3 – Step by Step”


I bought a Raspberry Pi 3 on the day it was announced, because I am easily excitable. When it arrived, I tried out a few things like compiling Synergy (much faster than a RPI2!) and the oblig. Quake 3. Once the fun wore off, I thought this might be a good time to finally sort out my cloud storage issues. The issues are as follows:

1) I am mildly concerned about having my data live on someone else’s computer
2) I really like and rely on Dropbox, but my 8GB isn’t enough anymore
3) I am a cheapskate

The solution for this is to self-host a ‘cloud’ storage system. While that’s a bit of a paradox, having a system (with apps!) that can have my files on me wherever I go and upload pictures I take on my phone automatically is too handy to give up – and too risky to have no real control over. The best open-source (free, see point 3 above) solution I’ve found so far is OwnCloud.

Note: If you want to do an OwnCloud install following this post – it doesn’t need to be on a Raspberry Pi 3 – you can do it on pretty much any Debian/Ubuntu server. One day I will move this whole thing to a proper server, but again, see point 3.

Note 2: There are hundreds/thousands/millions of ways to do this task. I am basing this whole thing on Dave Young’s very well written howto on Element14. In fact, you can probably follow that right now and skip my post – I am writing this down for my own benefit and there are a *few* changes in OwnCloud 9.0.1

OK, so what do you need to get this up and running?

  1. A Raspberry Pi 3 Model B – buy one here 
  2. A MicroSD card (Class 10 is speedy, you can get a 200GB one for $80USD at the moment, which is NUTS).
  3. The .img file for Raspbian OS. I suggest using Raspbian Jesse Lite
  4. An internet connection. Any one will do, but a decent 30/10Mbit/s is probably recommended.
  5. A static IP and a domain name (or a dynamic DNS service such as the one offered at system-ns.net)
  6. A keyboard and an HDMI capable monitor or screen. This is just for setting up the Pi
  7. Some basic Unix shell skills.. Although you can just follow along and hopefully I’ll spell everything out
  8. A router/firewall in your house that you can forward ports on

Optional extras:

  1. An external USB HDD (for more space)
  2. A smartphone, for the OwnCloud App

If you have the 8 things above (we’ll cover step 4 in some detail later) – then we’re good to start.

Steps to success

Section 1 – Setting up the Raspberry Pi 3

This section you can skip if you already have a freshly installed Raspberry Pi 3 running Raspbian.

  1. First up, install Raspbian OS on the SD card. Steps to do this for your main PC OS are here.
  2. When you have booted into your newly installed Pi, log in with username pi and password raspberry. You’ll change this soon. I suggest you do this bit with the Pi plugged into a TV or screen, with a keyboard. We’ll SSH in and control the Pi from another machine later on.
  3. Run the raspi-config tool – you can set your hostname, expand the file system (use all of your SD card, not just a couple of GB)

    pi@rasbian:~ $ sudo raspi-config

    rpi-confIn there, I suggest you run Option 1 and 2. Inside Option 9, I set the Memory Split to 4MB (this is mostly a headless install, why waste RAM on a GPU that won’t get much use), and enable SSH. I changed the hostname to ‘cloud’, pick a name you like. Finish up, then reboot the Pi

    pi@cloud:~ $ sudo reboot
  4. Find your IP address. I am using the Ethernet interface (physically plugged into a switch), but you could use WiFi if you wanted (Raspberry Pi 3 has in-built WiFi, google will show you how to set it up!)

    pi@cloud:~ $ ip addr | grep eth0 | grep inet
       inet brd scope global eth0

    Here is a command to show the IP DHCP has given you (Raspbian uses DHCP by default). I could set this manually by editing /etc/network/interfaces and changing eth0 inet DHCP to inet static, but I won’t be doing that. I’ll be assigning a static DHCP lease in my router config to keep my Pi on for good. ANYWAY – my IP is found, so I can SSH in from my main computer and live an easier life.

  5. Log in to your Pi from a terminal. iTerm2 for OSX, Putty for Windows, uhh, Terminal from *nix. I use password-less entry as a security feature and because I’m lazy – if you want a hand setting that up let me know – otherwise, you’re in and can run the following commands:

    pi@cloud:~ $ sudo usermod -a -G www-data www-data
  6. pi@cloud:~ $ sudo apt-get install nginx openssl php5-cli php5-sqlite php5-gd php5-common php5-cgi sqlite3 php-pear php-apc php5-curl libapr1 libtool curl libcurl4-openssl-dev php-xml-parser php5 php5-dev php5-gd php5-fpm memcached php5-memcache varnish php5-apcu git
  7. That chunky block will install some key pieces of software for us
    1. NGINX – the web server we’ll be using
    2. PHP5 – PHP, bane of all existence
    3. Lots of PHP bits and pieces, PHP5-apuc is the memory cache we’ll use, for example
    4. git – to allow us to grab a nice SSL certificate from Let’s Encrypt

Section 2 – Configuring and installing other bits

  1. Let’s get an SSL cert, so browsing to our Cloud will show a nice green lock in browser, and the OwnCloud app won’t complain *too much*. Of course, this also helps to keep the contents of the cloud machine nice and secure. I use Let’s Encrypt for free signed certificates – something you couldn’t even dream of 5 years ago. As there isn’t a packaged Let’s Encrypt installer for ARM7 Debian at the moment, we’ll use git to grab one:

    git clone https://github.com/letsencrypt/letsencrypt
    cd letsencrypt
    ./letsencrypt-auto --help

    This will grab Let’s Encrypt (the software) and chuck it in a folder in the pi user’s home directory called letsencrypt, then move us in there. It took about 10 minutes on my Pi 3 and reasonable internet connection, your results may vary.

    When that’s installed, we need to break out and get a DNS name (and a dynamic one, at that, as my ISP doesn’t offer static IP addressing)…

  2. Head to System NS, sign up and create a Dynamic DNS name. For the rest of this bit, I’ll refer to my domain as cloudy.system-ns.net. Next thing we need to do is automate the IP<>DNS mapping, as my ISP might pull the rug out and change my allocated IPv4 address at any time. System NS has a guide to do this for your OS (makes sense to do it on the Raspberry Pi, though!) – which can be found here.Basically, you create a file on the Raspberry Pi which tells the Pi to download the System NS page responsible for tying your current public IP to the chosen DNS name. Then you schedule it with crontab to run every 5 minutes. This means in the worst case, you will be a DNS orphan for around 5 minutes (System NS TTL for A records seems to be very short, which helps).
  3. OK – so now we have a domain, let’s get back to sorting out a SSL cert for it. As this Raspberry Pi will be used solely for OwnCloud (as far as the webserver side of things goes) I will generate the certificate for the /var/www/owncloud directory:

    pi@cloud:~ $ sudo mkdir /var/www/owncloud
    pi@cloud:~ $ cd ~
    pi@cloud:~ $ cd letsencrypt/
    pi@cloud:~ $ ./letsencrypt-auto certonly --webroot -w /var/www/owncloud -d cloudy.system-ns.net

    This will go away and pull a cert down from Let’s Encrypt. In fact, it will pull down a public certificate and a private key. They will be (by default) lurking in /etc/letsencrypt/live/cloudy.system-ns.net (you need to be root to look in there, which you can do with ‘sudo su’. Type ‘exit’ to get back to the pi user when you’re done gawking at the nice new certs.

  4. So, that’s some housekeeping done. Next, I’ll steal wholesale from Dave, and give a modified version of his NGINX config (remember, that’s the web server we installed back in section 1).Let’s edit the nginx config file! (Actually, let’s delete everything in it and start again)!

    pi@cloud:~ $ sudo nano /etc/nginx/sites-available/default

    This will open nano, the wusses text editor. I love it, because I can remember how to use it in a hurry. Anyway, delete everything in there (ctrl-k deletes a whole line at a time in nano).  Then edit this, and throw it in:

    upstream php-handler {
    #server unix:/var/run/php5-fpm.sock;
    server {
    listen 80;
    server_name cloudy.system-ns.net;
    return 301 https://$server_name$request_uri;  # enforce https
    server {
    listen 443 ssl;
    server_name cloudy.system-ns.net>;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    ssl_certificate /etc/letsencrypt/live/cloudy.system-ns.net/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloudy.system-ns.net/privkey.pem;
    # Path to the root of your installation
    root /var/www/owncloud;
    client_max_body_size 2000M; # set max upload size
    fastcgi_buffers 64 4K;
    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
    index index.php;
    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;
    location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
    location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) {
    deny all;
    location / {
                    # The following 2 rules are only needed with webfinger
                    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
                    rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                    rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
                    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
                    try_files $uri $uri/ index.php;
    location ~ \.php(?:$|/) {
                    fastcgi_split_path_info ^(.+\.php)(/.+)$;
                    include fastcgi_params;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    fastcgi_param PATH_INFO $fastcgi_path_info;
                    fastcgi_param HTTPS on;
                    fastcgi_pass php-handler;
    # Optional: set long EXPIRES header on static assets
    location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                    expires 30d;
                    # Optional: Don't log access to assets
                    access_log off;

    You can copy mine and replace all the bits with cloudy, etc..

  5. Now we can change the PHP settings to allow for larger uploads of files. Dave suggests 2GB, so we’ll go with that. In practice you can set it so whatever your filesystem allows. I’ll combo in a couple of steps here (changing where php-fqm listens as well)

    sudo nano /etc/php5/fpm/php.ini
    search for upload_max_filesize and set it to 2000M
    search for post_max_size and set it to 2000M
    sudo nano /etc/php5/fpm/pool.d/www.conf
    Then Change:
    listen = /var/run/php5-fpm.sock 
    to :
    listen =
    sudo nano /etc/dphys-swapfile
    Then Change:
    to :

    I didn’t follow all of these exactly, so I’ll copy-pasta Dave’s advice and leave you to try it out.

  6. Reboot the Pi!

    sudo reboot
  7. Now you need to install OwnCloud (hey, finally!). The way to do it on a Raspberry Pi 3 running Raspbian is simple.
    1. Grab the tarball from here

      pi@cloud:~ $ cd
      pi@cloud:~ $ mkdir downloads
      pi@cloud:~ $ cd downloads/
      pi@cloud:~/downloads $ wget https://download.owncloud.org/community/owncloud-9.0.1.tar.bz2
    2. Extract the files

      pi@cloud:~ $ sudo tar xvf owncloud-9.0.1.tar.bz2
    3. Now you end up with a nice folder called ‘owncloud’. We want to stick that where NGINX is looking for websites, so we’ll move it to /var/www, change the ownership of the folder to belong to the www-data user and delete all the evidence.

      pi@cloud:~/downloads $ sudo mv owncloud/ /var/www
      pi@cloud:~/downloads $ sudo chown -R www-data:www-data /var/www
      pi@cloud:~/downloads $ rm -rf owncloud*
    4. Dave now recommends you edit a couple of files in the /var/www/owncloud folder to tweak the filesizes:

      pi@cloud:~/ $ sudo nano .htaccess 
      Then set the following values to 2000M: 
      Php_value upload_max_filesize 
      Php_value post_max_size 
      Php_value memory_limit 
      pi@cloud:~/ $ sudo nano .user.ini 
      Then set the following values to 2000M: upload_max_filesize 
    5. Do a final ‘sudo reboot’
    6. Browse to your (whatever you called it) and set up OwnCloud. I have mine set to use the SD card for storage, if you wish to use an external HDD, consult Dave’s excellent post.
  8. When you first load OwnCloud it might complain about a few things, they can usually be solved by installing a memcache, tightening up file/folder permissions or tweaking other security features. As you have a valid SSL cert, you can probably get going pretty well straight away. I’ve added the necessary tweaks to the NGINX config that should get you past most of the pains, at least under Owncloud 9.0.1.
  9. That should be it! I lied, above, though. I use both the SD card and a backup onto an external HDD. This gives me the ability to live without my external HDD if I need it for anything temporarily, and keep 2 copies locally of all my stuff. To do it, I use a nice program called rsync and a little script + crontab to schedule it to run. rsync has a million uses, but one is copying files from one place to another in a really smart way, using deltas (i.e. it only copies the files that have changed). This way, I can schedule it to run every 6 hours, and it only takes as long as transfering the new or changed files to run.
    1. Install rsync!

      pi@cloud:~ $ sudo apt-get install rsync
    2. Create a script to run the sync..

      pi@cloud:~ $ mkdir scripts
      pi@cloud:~ $ cd scripts
      pi@cloud:~ $ nano oc-backup.sh
      sudo rsync -avz /var/www/owncloud/ /media/shamu/oc-backup/ | tail -n 2
      exit 0
      pi@cloud:~ $ chmod +x oc-backup.sh
      pi@cloud:~ $ crontab -e
      Add the following to crontab (which is a bit like nano, or vi, depending on what you select the first time you run it)
      0 0,6,12,18 * * * ~/scripts/oc-backup.sh >> /media/shamu/oc-backup.log
    3. Now every 6 hours from midnight that will run, doing an rsync and adding a date-stamped line to the file oc-backup.log. My 1TB external drive is permanently mounted to /media/shamu, by the way.

So, that’s it. Up and running. Mine has been working for 2 weeks now, approx 128MB of RAM free during normal operation (I check a little too often). php-fqm eats the CPU for breakfast when doing things like generating image previews in the app (I use the Android one and it’s great).. But mostly it all works. In fact, today I deleted my Dropbox app and all the files on it – I’m eating my own dogfood here, trusting this setup for better or worse. If you use it, let me know!

57 thoughts on “Owncloud 9.0.1 on Raspberry Pi 3 – Step by Step”

  1. By the way, I’m still happily using this setup with no changes from the above post.. Totally replaced my reliance on dropbox, love owncloud 🙂

  2. Thanks for the guide. New to this, but learning.
    I am running into problems with grabbing the cert. Do I need to forward ports before running “./letsencrypt-auto certonly –webroot -w /var/www/owncloud -d MYNAME.system-ns.net”?
    I am getting “could not connect to http://MYNAME.system-ns.net/.well-known/acme…..” error, but if I misspell the domain (and put in, for ex, cloudy.system-ns…), it gives me a different error (DNS Problem). Any advice?
    Also, the systemns cron job is working (they are updating the ip address every 5 minutes), but it isn’t filling up the log for some reason that is probably obvious.

    1. 1) Ok, so I forwarded 80 and 443 to my pi. So yes, ports do need to be forwarded (correct me if I am wrong) but now I am getting
      “Invalid Response. .. Make sure your domain name was spelled correctly and the DNS A records for that domain contain the right ip address”.
      I am calling:
      ./letsencrypt-auto certonly –webroot -w /var/www/owncloud -d MYDOMAIN.system-ns.net
      Any thoughts?

      Also, kind of nervous about just setting all 443 and 80 to forward to my pi. Do you know any good explanations of port forwarding (so I can try to forward as little as possible from my router || and so i can set up pi firewall–maybe fail2ban that bad boy)?

      1. Yes, you will need to have those ports forwarded to your webserver, sorry if I missed that out in the walkthrough.

        You could do a little port forwarding, so that you access your web-server from the outside on something like 10001, which your router then sends to 443 etc on the inside. Router specific guides are available all over. This doesn’t actually secure anything, just gives a bit of obscurity. If you want to really crank up the security a notch, look into IPTABLES. Reasonable guide here: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-basic-iptables-firewall-on-centos-6

        I rely on a very simple router firewall.

        For your other problem.. Can you reach even the nginx default page from outside?

    2. Hi Julian,

      The system-ns autoupdater doesn’t log properly for me anymore, either (last successful one was May 23). Something may have changed on their end, but as far as we care, if it works, we’re good.

      You could also do a quick shell script to compare the output of ‘curl ipv4.icanhazip.com’ with ‘host MYNAME.system-ns.net | awk ‘{print $4}’ ‘ and if they’re not the same, run the SystemNS script again, or send a mail or somesuch.

  3. Hello, great tutorial I must say. But I am stuck since up to this command

    -./letsencrypt-auto certonly –webroot -w /var/www/owncloud -d mydomain.system-ns.net

    I received an error saying it is not connected, due to firewall or ports issue.

    I had confirmed that my ISP has block most of the ports and port 80 and 443 is also blocks, what is the alternative way for me to get sort? Please help me

    Thank You

    1. I suspect you can tell your webserver (NGINX if you followed my steps) to use a different port, such as 8080. Then you will need to tell the let’s encrypt script to use that port when registering the certificate. Here’s a tutorial on how to do that: https://www.digitalocean.com/community/questions/nginx-ports-8080

      I have also been using CertBot to do my let’s encrypt stuff recently. It seems to only have a work-around for Apache (https://certbot.eff.org/faq/#can-i-issue-a-certificate-if-my-webserver-doesn-t-listen-on-port-80). Looking around on google, it seems like you might be out of luck – https://community.letsencrypt.org/t/port-80-and-443-blocked-by-isp-how-to-authenticate-domain/13065/4 .

      You could host your OwnCloud on a VPS like Linode or Amazon AWS to get around these issues, or just run without SSL.

  4. I got stuck on this step and wanted to share my solution. I should note I have another DDNS provider, but that shouldn’t matter.

    /home/yun/.local/share/letsencrypt/bin/letsencrypt certonly –webroot -w /var/www/owncloud -d myddns

    Failed authorization procedure. mydns (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://myddns/.well-known/acme-challenge/%5Bstring%5D

    My nginx server is working, I can reach it from the web and access files placed in the /html directory. I opened another ssh session while running the letsencrypt process and navigated to the /var/www/owncloud/.well-known directory and saw the /acme-challenge directory be created along with challenge string. However, once the script fails, this file is deleted. I tried putting a text file in my /var/www/owncloud/ directory, but I couldn’t reach it from the web.

    My solution was to change the /etc/nginx/site-available/default line:
    “root /var/www/html;”
    “root /var/www/owncloud;”

    Running the letsencrypt, I got a congratulations message
    – Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/xxx/fullchain.pem. Your
    cert will expire on 2016-11-12. To obtain a new or tweaked version
    of this certificate in the future, simply run letsencrypt-auto
    again. To non-interactively renew *all* of your certificates, run
    “letsencrypt-auto renew”
    – If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

    1. I am not sure about that, I just checked my running Owncloud server and nginx-extras/light are not installed. Did you run into a particular problem without them installed?

  5. Sorry I need help I do this installation but there’s a mystake
    I can access at home
    But outside I Can’t
    I have a static IP on my box but nothing
    sorry I don’t speak well english
    Someone can help me thanks

    1. Bonjour Thierry 🙂

      Have you created a rule on your home router to direct traffic through to For example, on my router I have three rules that forward port 80, 443 and 22 to (which in my case, is the raspberry pi). Port forwarding is offered by pretty much any router on the market, and you can get help on portforward.com for your device.

      You might not want to have port 22 (SSH) for example forwarded, so you can do port translation to expose a non-standard port number to the outside instead – but I don’t bother with this (I enforce SSH keys on my SSH sessions).

  6. Having issues at Browse to your (whatever you called it) and set up OwnCloud.
    I used .12 instead of 13, I have running a webserver so I wanted this pi @ running my cloud. When I go to in my browser it just says site cant be reached. Tried to start the nginx service but that failed due to Job for nginx.service failed. See ‘systemctl status nginx.service’ and ‘journalctl -xn’ for details.
    pi@mycloud:~ $ systemctl status nginx.service
    ● nginx.service – A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
    Active: failed (Result: exit-code) since Mon 2016-12-05 18:43:13 UTC; 4min 19s ago
    Process: 9604 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

    Googled it not really getting the issue, if you could explain it better id be grateful

    1. I’m a bit confused – you’re running .13 as your nginx webserver, and the Owncloud install on another machine with .12?

      Can you upload your nginx /log files to pastebin or something?

  7. Here’s one for you:-
    Couldn’t access my ownCloud server using my external IP and I was racking my brains trying to find out what was wrong. Finally, I found out what the issue was. My ISP assigns me a DualStack IPv6 address, as opposed to a normal IPv4. I don’t suppose you know if there’s a solution for this?

    1. When you say dualstack, you mean you get an IPv4 and IPv6 address assigned? I assume you get only a singular (/32 and /128 respectively) address from your ISP, and that it’s static.

      If so, you’ll need to make sure you have an IPv6 address configured on your Owncloud server, and configure nginx (or Apache) to listen on that IPv6 address. Your router will also need similar config as mentioned for IPv4 to pass the HTTPS requests (port 443 in our example) through to the IPv6 address (i.e. you will need port forwarding done for IPv6 as well).

  8. Thanks for the reply, James. I’m not entirely sure about DualStack, as it’s quite a new concept to me and it was only after a bit of digging around I found that this was the reason why I couldn’t connect.

    My router (FritzBox 7360) reports that I’m connected to both IPv4 and IPv6 connections and yes, I get two separate 32bit and 128bit addresses. When I curl icanhazip.com, normally it reports the IPv6 address but sometimes can report the IPv4. I’ve now updated the config.php and sites-available configuration to also listen on the IPv6 address (using a guide over at owncloud.org). My router has a separate IPv6 port forwarding configuration page, so, as a test, I disabled the IPv6 firewall and opened up all traffic to the Pi. Still no joy so far.

    If I do eventually get this working, I’ll have to also move to a DDNS service which supports IPv6 records. It seems that this is possible, but there’s a bit of tweaking to do and I think my issue is with the router now. I’ll be sure to report back IF I find a solution!

    1. OK..

      First up, can you browse to your server on the IPv6 address DHCP (or autoconfig) has assigned? If you do an ifconfig on the Raspberry Pi and look for the v6 address, try and browse to it.. If that part doesn’t work, you’re cooked.

      You need to make sure your server is listening on its own address, not that of the router (that’s what the port forwarding is for).

      https://dynv6.com/ – this exists – not sure if it works well/is reliable.

  9. Hi james,

    Thank you very much for your well written guide…I have a question about getting DNS name (your guide section 2/step 2). I’m assuming that suggested settings are for the users who don’t use routers with possibility to set up dynamic dns.
    I’m using for years DynDNS.org as the DNS provider for my devices in my network. I have a router with DynDNS account set up and all my devices using a static IP address within my network. Than I forward the ports on the router to set up access to my devices from “outside world”. Do I still have to follow the step2 and what settings to use for DynDNS.org? (p.s. I did not follow the step 2 in my first installation and i was getting the error with the cert)


    1. Hello, thanks for reading.

      Correct, these are guides for people whose router (like my crappy Virginmedia one) either doesn’t support Dynamic DNS or they simply don’t want to do it. You can simply forward the port to your Owncloud instance machine (Raspberry Pi, in my case) and carry on as normal 🙂


    1. Hey Jaime, nope I haven’t. I have however just fired it up using Docker on my home unraid hypervisor, and it’s amazingly simple.

  10. On #5 I’m getting the message: “E: Unable to locate package php5-apcu”. Google hasn’t helped me figure it out thus far. Any tips on how to correct this?

      1. I had been just pasting in the block of commands from #5 and it would just give me the above error.. nothing else would install. I ran it with php5-apcu removed and it all installed without issue.

          1. Hi James, I just wanted to let you know that I think my issue had to do with the distro version that I was running… I was on Wheezy. I updated to Jessie and all went well.

  11. Hi James,

    I’ve been stuck for hours at the same spot as others have, that is at the point of getting the SSL certificate in step 3:

    ./letsencrypt-auto certonly –webroot -w /var/www/owncloud -d cloudy.system-ns.net (where i replaced “cloudy” with my own domain name, of course)

    I’ve been trying all the solutions proposed by the others like the one from RW:

    # My solution was to change the /etc/nginx/site-available/default line:
    # “root /var/www/html;”
    # to
    # “root /var/www/owncloud;”

    Which still doesn’t do it….I even tried the line he posted and that isn’t what you put in your tutorial (Wonder where did that come from…??):

    # /home/yun/.local/share/letsencrypt/bin/letsencrypt certonly –webroot -w /var/www/owncloud -d myddns (Again here, i replaced “myddns” with my own dns, and “yun” with “pi”, of course…)

    My router has both port 80 and 443 forwarded to the raspberry pi and i double-checked everything i could think of and still get that error:

    Failed authorization procedure. rpicloud.system-ns.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://rpicloud.system-ns.net/.well-known/acme-challenge/5dpaQsGvoADNveYojTaSX1ScCe7t4v0DB3JTH0SQn1E: ”
    404 Not Found

    404 Not Found

    – The following errors were reported by the server:

    Domain: rpicloud.system-ns.net
    Type: unauthorized
    Detail: Invalid response from

    404 Not Found

    404 Not Found

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address.

    I’ve tested without port forwarding on the router just to see what difference it would make and got this error:

    Failed authorization procedure. rpicloud.system-ns.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to rpicloud.system-ns.net

    – The following errors were reported by the server:

    Domain: rpicloud.system-ns.net
    Type: connection
    Detail: Could not connect to rpicloud.system-ns.net

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

    Which seems to imply that the procedure is getting through to the pi, when port forwarding is set on the router, i think…..!!??

    I’m really desperate as this is the third tutorial I’m trying and I find yours much better regarding the method with Dynamic DNS domain name and free signed SSL certificate from “Let’s Encrypt”, which where both great things to discover and learn as I’m quite a newby at all this…

    Hope you can help me out…..Thanks for all the great work…!!!


    1. Yo –

      I think you might have something wrong with the path to your www/ folder, but I can’t really give a definitive answer. Might I suggest you try Certbot to do the SSL parts – the EFF have built a lovely front-end for the Let’s Encrypt service – https://certbot.eff.org/

      Try that (ignore my SSL instructions) and let me know how you get on.


  12. Thanks for that,

    I’m on certbot website and Tried the “nginx/debian 8(jessie)” with adding

    deb http://ftp.debian.org/debian jessie-backports main

    to /etc/apt/sources.list.d/raspi.list

    then sudo apt-get update

    then got this error:

    W: Erreur de GPG : http://ftp.debian.org jessie-backports InRelease : Les signatures suivantes n’ont pas pu être vérifiées car la clé publique n’est pas disponible : NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010

    so now i’m trying with “nginx/debian(other)” with:

    wget https://dl.eff.org/certbot-auto
    chmod a+x certbot-auto

    And got this message:

    Failed to find apache2ctl in PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    Certbot doesn’t know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run “certbot-auto certonly” to do so. You’ll need to manually configure your web server to use the resulting certificate.

    After that i don’t understand which i should use: certonly or webroot plugin:

    From the certbot website:
    “Since your server architecture doesn’t yet support automatic installation you should probably use the certonly command to obtain your certificate.”
    ” If you already have a webserver running, we recommend choosing the “webroot” plugin. ”

    Sorry if i’m so confused, with all the error messages i keep getting with every step i just can’t understand how to proceed…..!!?!?

    Meanwhile, I’d like to make some simple tests, like accessing my www/ folder from the outside of my home network, to make sure that works both directly and with the DNS, but i’m not sure i’m doing this right…
    I tried with:

    http://MY EXTERNAL NETWORK IP/index.nginx-debian.html


    and it doesn’t work….

    Also, i wonder if there could be an issue with either the ownership or the permissions of the /var/www/ directory….

    here is the result of “ls -l /var/www”:

    drwxr-xr-x 2 root root 4096 jan 25 18:49 html
    drwxr-xr-x 3 root root 4096 jan 25 20:13 owncloud

    Is that alright…?

    Again sorry if i’m a lot of work, i’ve been using linux for several years, my portable computer runs on linux mint, and i’ve got 3 raspberry pi on which i experemented successfully a lot of cool stuff. I’ve been doing a lot of reading for this owncloud project, on all the subjects concerced.
    I should be close to the solution……But still need a little help..!


    1. I would love to help more but I am away from my home and computers. I will be back mid next week.

      Your first comment mentions an Apache error, but this example we’re using nginx, so I think you’re not driving certbot properly. From memory I used webroot (as a flag) and it “just worked”. If you can wait for me to get back I can probably help you more.

      If you get that Apache error, it’s something you need to fix as well, but shouldn’t be relevant to this tutorial.

  13. Ok, i think i understand, certonly is a command, webroot is a plugin to use after invoking ./certbot-auto certonly…..!!!

    So i try this:

    ./certbot-auto certonly

    and get this error again, which i wonder if it is important or not:

    Failed to find apache2ctl in PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

    But i keep going anyway and choose to authenticate the ACME CA using webroot directory(webroot), but after entering my domain name, it asks to enter a new webroot, and i don’t understand what i’m supposed to write there….I’m reading about this on the certbot site, and to which location it’s supposed to be put in, /var/www/html or /var/www/owncloud or /usr/share/nginx/html ???
    So i tryed /var/www/html but i’m still getting the same error “The client lacks sufficient authorization” and an “invald response” from http://rpicloud.system-ns.net/.well-known/acme-challenge/etc

    There’s something i’m doing wrong during this procedure, or some configurations are missing somewhere, but i just can’t see what it is…??

    So about nginx:
    -do i have to stop the server during these procedures..?
    -Is there some changes to make to the nginx configution file about serving hidden files…?

    I keep reading, and trying other options, but if you can clarify some of the points mentionned in this post and the previous one, i’ll be most grateful as i’m having such a hard time understanding some of that stuff…

    Thank you for your patience


    1. Hi nomadelog, I was having the same issue, and this is what helped me get past it… I followed the steps under “How to Use the Webroot Plugin” on this page: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
      before I ran the ./letsencrypt command
      (While editing the /etc/nginx/sites-available/default file I also replaced /var/www/html with /var/www/owncloud)
      After following those steps and restarting nginx, letsencrypt worked for me.

  14. It took me hours and hours to get this right, and I wouldn’t have had a chance without your help. But in the end I managed it on a completely clean install of raspbian Jessie. So, before the vent, thank you for your really clear and helpful effort.

    There are three small things I noticed, and one big one.
    The big one is that letsencrypt is the spawn of the devil. I have not dealt with anything so unhelpful and badly documented since demon systems started up in 1992.
    The small thing is that it will none the less work if your instructions are followed *in the order you give them*.

    Letsencrypt relies on the nginx configuration being completely stock and if you try to run it after installing owncloud and configuring nginx for it only tears and horror can follow.

    secondly, if you want to run owncloud on a subdomain of your dyndns/fixed ip address, you have to configure a dns record to point to it. ie, if you owned planetary.space and want to set up owncloud on oortcloud.planetary.space, there has to be a separate dns record somewhere pointing to oortcloud.planetary.space as well as the one which points to planetary.space anyway. Otherwise letsencrypt will throw up an error.

    Thirdly, when it finally runs right, letsnotbesostupid will install the certificates, by default in a directory that nginx cannot read. So you have to chmod 755 both /etc/letsencrypt/live and /etc/letsencrypt/yourownclouddomain

    Finally, I wondered why not use the very much simpler method suggested in Dave Young’s post, which was only a one-liner?

    1. Cheers Andrew

      I think this post could almost use a re-write.. I am no longer running Owncloud on a Raspberry Pi, in fact I’m using MariaDB in a container and Debian 8 in a VM to do the job – it’s a lot quicker – if you have the hardware/infra. Back to the point..

      The guide as written is meant to be followed in order, mainly so I can remember how I did it if I have to do it again. Instead of Let’s Encrypt! I’ve been using the slightly more easy-to-use CertBot from the EFF, which you can find here: https://certbot.eff.org/

      I can’t remember why I went off-piste from Dave’s suggestion – probably ran into an error and just wrote down what worked for me with no deviation allowed.

  15. Hello,

    I’m searching for help:
    I am an Linux user from germany since a few years, mainly because of DIY reasons.

    I got two Pi3’s for my birthday and want to use on as a cloud. I have:
    The Pi, an 16GB Card for the OS and 2 2TB external HDDs from WD. One for the PI, one as a backup. I thought about use OpenMediaVault with OwnCloud, then I found your guide. Maybe it’s better this way.

    My main question: Is the guide still usable, and for what?
    So can you just excange files or is it also possible to sync my Calendar and Contact list. Auto-Upload of photos is possible, right?

    Best regards,

    1. Hi Cronyk,

      I haven’t run this guide for a while, but in priciple it’s still valid. You could use your Pi with 1 of the 2TB drives as Owncloud, and use rsync or similar to keep a backup of the OwnCloud file directory onto the other drive.

      The Desktop and mobile apps for Owncloud are very nice (similar to Dropbox) – I use both to drag n drop files on my desktop, and auto upload cellphone pics/videos when on Wifi.

      Best of luck implementing it yourself, if you have trouble let us know.


  16. Hello again James, I ran into a few problems

    Section 1.5: I don’t understand passwordless entry, but i don’t mind typing PWs, so I skipped this step.

    Section 2.2: I have an Domain at selfhost.eu so I also skipped this step, including the IPDNS mapping. Reason: I don’t understand it and I ran in no problems with my OpenMediaVault server so I think it isn’t needed here.

    Section 2.3: The first REAL problem:
    I changed the command at the end to
    ./letsencrypt-auto certonly –webroot -w /var/www/owncloud -d cronyk.selfhost.eu

    And I got:

    – The following errors were reported by the server:

    Domain: cronyk.selfhost.eu
    Type: connection
    Detail: Fetching

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

    I couldn’t resolv the puzzle and simply moved on to
    Section 2.7.4 where I got stuck:

    sudo mv owncloud/ /var/www
    mv: das Verschieben von „owncloud/“ nach „/var/www/owncloud“ ist nicht möglich: Das Verzeichnis ist nicht leer

    mv: the moving of „owncloud/“ to „/var/www/owncloud“ is not possible: The folder is not empty

    Variations with -f -r -uv didn’t help.

    No idear how to move on.


  17. Hi – I think having so many problems in one post is going to be a challenge.

    I would now recommend you use CertBot instead of letsencrypt-auto – it can make things a little more simple. Check it out here – https://certbot.eff.org/

    Is that domain already pointing at the correct IP address – i.e. when letsencrypt tries to validate, is it resolving against your Raspberry Pi?

    Instead of mv, you can try cp.. Then rm -rf the original.

  18. E: Package ‘php-apc’ has no installation candidate
    E: Package ‘php5-memcache’ has no installation candidate
    E: Package ‘php5-apcu’ has no installation candidate

    1. Hi Geff

      I am not familiar with that OS – but if it’s based on Ubuntu, then yes it should work fine. If you run into trouble, please let me know and I’ll take a look.

Leave a Reply to RW Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.