Secure Owncloud Server

This article is about how to securely configure the machine where your Owncloud instance will be running.
Even if you set-up your connection with Owncloud in a secure way,  your data still can be compromised by exploiting security flaws in the underlying architecture.

In the following we specifically will cover the underlying software stack and brute-force password hacking attempts.

Automatically install security updates

No software package is perfect – there might be security holes in the the whole stack – starting with the linux kernel up to the used SSL library.
However most security holes that are being exploited are publicly known and security updates have been provided for them.
The only reason why they still can be exploited is that people do not install the security updates in time. Especially if there is no server-admin dedicated to maintaining the Owncloud machine one might easily miss on such updates.

Fortunately it is very easy to enable automatic security updates on debian based distributions with

sudo dpkg-reconfigure -plow unattended-upgrades

Starting with owncloud 8.2, there are per release package sources, so it is safe to also include owncloud itself in the unattended-upgrades. To do so add the following line to



Prevent brute-force password hacks

Unfortunately Owncloud 9.1 is still vulnerable to brute-force password attacks in its default configuration as it does not enforce timeouts after failed login-attempts.

Therefore one might just try all possible passwords gain access to your machine in about 3 days for a typical password length:

To prevent this we can use fail2ban to enforce a timeout after a certain number of failed login attempts.

First install fail2ban

sudo apt-get install fail2ban

Fail2ban works by parsing the log files of a service and then reconfiguring the firewall in order to ban the offending ip-address.

So we need to tell owncloud to log the failed login attempts. To do so edit


  'logtimezone' => '<TIMEZONE>', // e.g. 'Europe/Berlin'
  'logfile' => '/var/log/owncloud.log',
  'loglevel' => '2'

Note that logtimezone must match the clock of your server. Furthermore the webserver user (e.g. www-data) must have write access to the logfile. To verify that logging works, do some failed logins and check /var/log/owncloud.log.

Next create the following filter definition for fail2ban


failregex={"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"}

Together with the following service definition


enabled = true
filter  = owncloud
port    = https
logpath = /var/log/owncloud.log

Now restart fail2ban and try to log in 4 times with a wrong password. The 4th attempt should give you a timeout. (for 15min)

If you do not get the timeout you should verify that fail2ban correctly reads the log by

fail2ban-regex /var/log/owncloud.log /etc/fail2ban/filter.d/owncloud.conf
  • good stuff, I’m going to implement this right now on my owncloud, thx

    • David

      Guys, I found the issue why it’s not working, for me it was the timezone, because, of course, fail2ban needs to know the times when someone accessed the owncloud instance:)

      ‘logtimezone’ => ‘Europe/Vienna’,

      Instead of

      ‘logtimezone’ => ‘UTC’,

  • Siegie

    Thank you, just what i needed. But there’s still another hole i would like fix. If you share a file you can secure it with a password. The invalid ones are not track in this way.

  • jaebiddy

    I could not get this to work. Restarting fail2ban seemed to pass the settings without a problem but when I make the login attempts it doens’t ever give me the message or stop be from continuing to log in.

    • rojtberg

      it should not give you any error message – it should simply block you from the server for 15min.
      Take a look on /var/log/fail2ban.log and on /var/log/owncloud.log to find out whats going wrong.

      • jaebiddy

        /var/log/fail2ban.log shows the service starting the the owncloud jail running. /var/log/owncloud.log does not seem to exist. I’m not sure why it’s never created, I’ve tried logging in with a wrong password 5+ times and I don’t see any lines in the fail2ban.log other than that the owncloud jail is starting and running.

        • rojtberg

          fail2ban works by parsing owncloud.log – so if it is not there fail2ban cant possibly work.
          Did you edit owncloud/config/config.php as suggested?
          Also check the log on the owncloud administration page.
          A wild guess would be that the php user has no write permissions to /var/log/.

      • jaebiddy


        ‘logfile’ => ‘/path/to/owncloud/data-directory/owncloud.log’,

        or are we explicitly creating a new logfile for this process?

        • rojtberg

          Then this is the file that should be referenced in /etc/fail2ban/jail.local.
          also take a look whether it contains any info about failed log-in attempts.

          • jaebiddy

            Hmm. I have changed the path in /etc/fail2ban/jail.local to read ‘logfile’ => ‘/var/www/owncloud/data/owncloud.log’

            Viewing that file shows the login attempts being written to the log file, however entering wrong passwords still doesn’t seem to lock me out for any amount of time.

          • AL

            Brother, its the post updated with all this info? I installed 7.0.1 and having some issues as well..trying all the solutions from the comments..still no blocking! 🙁

  • birdonwheels5

    Fail2ban doesn’t like the ISO8601 format that ownCloud uses, so in order to make it work right you need to follow the last post over here:

    Basically it switches to a different format that works with fail2ban. Just tested it myself, and it locked me out right away! Make sure you change the locations of the log files in ALL the configs.

    • rojtberg

      for me fail2ban 0.8.11 works fine with ISO8601

  • Userk

    Owncloud 7.0.2 the Fail2ban doesn’t work with this . Whats the Problem with the Code. On 7.0.1 it works without Problems 🙁

    • rojtberg

      check your owncloud.log for the “wrong password” warnings. also compare the logged time with the server time

    • rojtberg

      the changed the log format in 7.0.2. I updated the filter definition to match both.

  • utack

    My owncloud did not have access to /var/log. Had to drop the log in /var/www/owncloud but it works great.

    • Jan

      You shouldn’t put logs into a folder that is accessible by the webserver (someone might inject an url containing code and try to use it with an attack). Instead use chgrp and chmod g+w to grant access to a subfolder of /var/log to owncloud.

      • utack

        Thanks. There are always things to learn.
        Who exactly should be owner of my new /var/log/owncloud folder?

        • Realist08

          i used the same user/group as my apache2 folder has set, seems to work here.

  • Pingback: Prevent brute force attacks against ownCloud | Monotok()

  • Happy reader

    Thanks for the article. I had to change the log file to owncloud/data/owncloud.log.

  • chmedly

    So, I’m trying to configure fail2ban for OC 7.04. I’m not having any luck with OC writing to the owncloud.log file mentioned in this write up. It appears that the log_authfailip function has been removed and failed log in attempts are now logged through checkPassword.

    I’m still researching how to adjust fail2ban for this change.

    • have you found a solution?

    • rojtberg

      the second row in /etc/fail2ban/filter.d/owncloud.conf should still match with OC 7.0.4. As far as I can see this is the change I already noticed with 7.0.2.

  • hmm i keep getting this message when i am trying to restart

    root@techknight:/home/daniel# nano /etc/fail2ban/filter.d/owncloud.conf
    root@techknight:/home/daniel# service fail2ban restart
    * Restarting authentication failure monitor fail2ban ERROR Failed during configuration: File contains no section headers.
    file: /etc/fail2ban/filter.d/owncloud.conf, line: 1
    ‘{“app”:”core”,”message”:”Login failed: ‘.*’ \(Remote IP: ”, X-Forwarded-For: ‘.*’\)”,”level”:2,”time”:”.*”}n’

    • rojtberg

      seems you forgot to place [Definition] above the regex in /etc/fail2ban/filter.d/owncloud.conf. compare your config with the post.

      • my config gile looks like this as it is the newest owncloud

        failregex={“app”:”core”,”message”:”Login failed: ‘.*’ (Remote IP: ”, X-Forwarded-For: ‘.*’)”,”level”:2,”time”:”.*”}

        it still says it needs an definition ?

  • din0

    Thanks for the writeup, just implemented this right now on my OC instance and it’s working as intended. (OC 7.04)

  • OhStopItYou!

    I followed exactly everything you have mentioned. It does not seem to work. I don’t get timed out 🙁

    • rojtberg

      does logging work? i.e. do you see log messages in /var/log/owncloud.log after failed login attempts?

      • OhStopItYou!

        Yep. I can see the failed attempts. Moreover if I run fail2ban-regex /var/log/owncloud.log /etc/fail2ban/filter.d/owncloud.conf
        I get the following result:
        Lines: 72 lines, 0 ignored, 54 matched, 18 missed

        • rojtberg

          assuming you made indeed 54 login attempts, is the logged time correct? compare with the output of “date” on your server.

          • OhStopItYou!

            Date: Sat Feb 14 11:32:52 EST 2015
            owncloud.log output (a single line):

            “”,”app”:”core”,”message”:”Login failed: ‘a’ (Remote IP:’′, X-Forwarded-For:

          • rojtberg

            honestly, I am out of ideas. The only thing left is that fail2ban fails to ban. take a look at /var/log/fail2ban.log

          • OhStopItYou!

            it does ban it on logs, but it deos not seem to work

          • OhStopItYou!

            I finally figured it out. I modified the regex a little bit.
            This might help with Owncloud 8.0.2 🙂 Thanks a lot for this tutorial. I learnt a lot.

            {“reqId”:”.*”,”remoteAddr”:””,”app”:”core”,”message”:”Login failed: .*”,”level”:2,”time”:”.*”}

        • dsjiern

          I had the same problem. The solution for me:

          in jail.local the default-backend is set to systemd. But when using a separate logfile for owncloud you have to set the backend in the [owncloud]-section to polling.

          Now it works for me.

  • Ryan

    Worked perfectly for OC 7.0.5. Thanks!

  • Pingback: Setting Up a Centos 7 Server for Owncloud from Start to Finish | Random ideas on just about everything!!()

  • Povl Falk-Jensen

    Thank you for this fine tutorial.

    I’m running OwnCloud v7.05 and Fail2ban v0.9.1 on a Fedora 21 server so I had to make the following changes to make i work:

    1. In “/etc/owncloud/config.php” I changed ‘log_type’ => ‘syslog’ (default) to ‘log_type’ => ‘owncloud’. Before I made this change, nothing would be written to “/var/log/owncloud.log”. Source:

    2. On Fedora 21 the webserver user and group is “apache” (not “www-data”) so I changed the ownership of “/var/log/owncloud.log” to “apache”: “chmod apache:apache /var/log/owncloud.log”.

    3. I placed “jail.local” in the folder “/etc/fail2ban/jail.d/” since it’s recommended by Fedora.

  • Pingback: Secure your ownCloud server | 0ddn1x: tricks with *nix()

  • carlberg

    thanks a lot for this how2!
    Seems to work on my system OC 8.1.1 on debian wheezy
    (I also did chown www-data:www-data /var/log/owncloud.log)
    Thanks a lot!!

  • Emil Eliason

    Thanks for this, great guide!

  • spiroseliot

    I am trying to setup fail2ban but everything seems ok but fail2ban is not working. I can do many fail attempts to login.

    I have verify that fail2ban correctly read the logs.

    And i have edit owncloud.conf like with the instructions.

    When i restart service i have this warnings

    * Restarting authentication failure monitor fail2ban WARNING ‘ignoreregex’ not defined in ‘Definition’. Using default one: ”

  • pdwalker

    Thank you. This is a fantastic help.

  • Pingback: Installing OwnCloud on Ubuntu Server 14.04 – ItChris Blog()