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.
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:
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.
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:
ask_authis set to
davfs2will 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
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
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_sizeoption, say to
2048. This value should be a power of 2.
delay_uploadparameter sets how much time
davfs2will 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
If you are using a GUI to view your files (chances are pretty good you are) set
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
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 (
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
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.