Mounting ownCloud accounts with davfs2 on GNOME3

2016-05-30 - Louis-Philippe Véronneau

This post aims to share how easy it can be to mount ownCloud's WebDAV shares on GNOME3.

Why do this?

At SOGÉÉCOM, our users love to use ownCloud. It works nicely, has a beautiful web interface and even gives you access to your files on your phone, be it Android or iOS.

So yeah, ownCloud is great, but from a sysadmin's point of view, it can be a bit of a trouble sometimes. Our setup involves some client computers running Debian with GNOME3. Since these computers are used by multiple users each day, we cannot use ownCloud's sync client. It would duplicate a lot of files for nothing and users would constantly need to wait for files to sync when they log in.

The solution we found to fix this problem is to dynamically mount a user's ownCloud account through WebDAV. The result is pretty good, but vastly depends on:

the latency between the client computer and the server
the speed of the server your running ownCloud on
the speed of your network connection

The best setup would thus be if you were able to run ownCloud on a physical server in your office. We don't but our server pings at 100ms and we have a pretty good network connection.

Introducing davfs2

The best way to mount WebDAV on Debian is to use davfs2. To install it, you can run:

$ apt-get install davfs2

davfs2 has two main configuration files:

/etc/davfs2/davfs2.conf
/etc/davfs2/secrets

The first one harbors davfs2's configurations, while the second lists all the usernames and passwords the program will need to connect to your ownCloud server.

davfs2.conf

To know what all parameters do, you can check out the man page of this configuration file:

$ man davfs2.conf

The default parameters are pretty sane, but a few things should be changed nonetheless:

If ask_auth is set to 1, davfs2 will interactively ask for credentials if it can't find them in /etc/davfs2/secrets. Since we don't want to bother users with this, set it to 0.
When we implemented our setup, ownCloud's WebDAV file locking mechanism was pretty buggy, so we decided not to use it. Since then, we have not looked back on it and truly, it was not missed. We recommend to set use_locks to 0, but if you want to play around with this parameter, please do so.
If you have big filesystems (ours is pretty big), it is a good idea to increase the value of the table_size option, say to 2048. This value should be a power of 2.
The delay_upload parameter sets how much time davfs2 will wait before uploading a file when it is closed. We had some trouble about files disappearing for no reason when they were modified. Setting this option to 30 fixed it.
If you are using a GUI to view your files (chances are pretty good you are) set gui_optimize to 1.

The result looks like this:

# version 11
# ------------------------------------

# Copyright (C) 2006, 2007, 2008, 2009, 2012, 2013, 2014 Werner Baumann

# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.


# Please read the davfs2.conf (5) man page for a description of the
# configuration options and syntax rules.


# Available options and default values
# ====================================

# General Options
# ---------------

# dav_user        davfs2            # system wide config file only
# dav_group       davfs2            # system wide config file only
# kernel_fs       fuse
# buf_size        16                 # KiByte

# WebDAV Related Options
# ----------------------

# use_proxy       1                 # system wide config file only
# proxy                             # system wide config file only
# trust_ca_cert         /etc/davfs2/certs/GandiStandardSSLCA.pem

# servercert                        # deprecated: use trust_ca_cert
# trust_server_cert     /etc/davfs2/cert.pem
# clientcert
# secrets         ~/.davfs2/secrets # user config file only
ask_auth        0
use_locks       0
# lock_owner      <user-name>
# lock_timeout    1800              # seconds
# lock_refresh    60                # seconds
# use_expect100   0
# if_match_bug    0
# drop_weak_etags 0
# n_cookies       0
# precheck        1
# ignore_dav_header 0
# use_compression 0
# follow_redirect 0
# server_charset
# connect_timeout 10                # seconds
# read_timeout    30                # seconds
# retry           30                # seconds
# max_retry       300               # seconds
# add_header

# Cache Related Options
# ---------------------

# backup_dir      lost+found
# cache_dir       /var/cache/davfs2 # system wide cache
#                 ~/.davfs2/cache   # per user cache
# cache_size      50                # MiByte
table_size      2048
# dir_refresh     60                # seconds
# file_refresh    1                 # second
delay_upload    30
gui_optimize    1
# minimize_mem    0

# Debugging Options
# -----------------

# debug           # possible values: config, kernel, cache, http, xml,
                  #      httpauth, locks, ssl, httpbody, secrets, most

secrets

This file lists all the usernames and the passwords davfs2 will need to connect to ownCloud. You should fill it like this:

user1   user1_password
user2   user2_password
user3   user3_password

This file is pretty sensitive. To be sure no one but the administrator can read it, modify its permissions:

$ chmod 600 /etc/davfs2/secrets

Dynamically mounting with PAM

The "dynamic" part of our mounting process (i.e. when a user logs in, the account in mounted automatically) is done with the help of PAM, a great and powerful tool.

The file we will be modifying here is /etc/security/pam_mount.conf.xml. You can read its man page by typing:

$ man pam_mount.conf

This file is written in XML and only few things needs to be modified for our setup to work. Your job will mainly consist in writing volume definitions in this style:

<volume user="user1" fstype="davfs" path="https://fqdm.org/remote.php/webdav/" mountpoint="the/mountpoint/path" options="uid=user1,gid=user1_group,file_mode=0770,dir_mode=0770" />

The options bit is pretty important, because if you set different permission, users will have trouble reading their files from the mount point.

Since we are potentially dealing with a lot of users here, you should probably read about the behavior of the /etc/skel directory. We use it to create a standard mountpoint in a user's directory (~/ownCloud).

Our pam_mount.conf.xml kinda looks like this, but with real values:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
  See pam_mount.conf(5) for a description.
-->

<pam_mount>

    <!-- debug should come before everything else,
    since this file is still processed in a single pass
    from top-to-bottom -->

<debug enable="0" />

    <!-- Volume definitions -->

<volume user="user1" fstype="davfs" path="https://fqdm.org/remote.php/webdav/" mountpoint="the/mountpoint/path" options="uid=user1,gid=user1_group,file_mode=0770,dir_mode=0770" />

<volume user="user2" fstype="davfs" path="https://fqdm.org/remote.php/webdav/" mountpoint="the/mountpoint/path" options="uid=user2,gid=user2_group,file_mode=0770,dir_mode=0770" />

<volume user="user3" fstype="davfs" path="https://fqdm.org/remote.php/webdav/" mountpoint="the/mountpoint/path" options="uid=user3,gid=user3_group,file_mode=0770,dir_mode=0770" />


    <!-- pam_mount parameters: General tunables -->

<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<logout wait="0" hup="0" term="0" kill="0" />


    <!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

TAADAAA! If you did follow these instructions correctly, when you log in an account, you should now see an ownCloud WebDAV share mounted.

If not, logging in a terminal session is pretty useful. If something fails, davfs2 will tell you. If you can't figure it out, you can always try to get more infos by enabling the debug parameters in davfs2.conf and pam_mount.conf.xml.

Problems

As well as this setup works, there are still a few problems you should be aware of:

This is not made for massive file modifications. If someone tries to copy a 30Gb directory with the davfs mount, you will have problems.
There can be a quite big lag when opening a directory (10 seconds and more) if you have a bad ping or a bad network connection.
All of your users' ownCloud passwords are in kept in plaintext on the client's drive. Please don't add your administrative account in the list, this could end up badly.

owncloud gnome