Mount davfs einer webdav-Freigabe

UCS - Univention Corporate Server
#1

ich möchte gerne in mein filesystem eine webdav freigabe mounten.

mount -t davfs http://ipadresse/verzeichnis /mnt/point
mount: unknown filesystem type ‘davfs’

wie kann ich davfs nachinstallieren?

mein system:
4.3-3 errata419 (Neustadt)

apt install davfs2
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen… Fertig
E: Paket davfs2 kann nicht gefunden werden.

#2

you should activate unmaintained repo first:
ucr set repository/online/unmaintained='yes'

https://docs.software-univention.de/handbuch-4.3.html#computers:Konfiguration_ueber_Univention_Configuration_Registry

#3

Thank you very much for your fast reply - that really helped and I was able to install davfs:
univention-install davfs2

now I got the next issue:
mounting manually works fine:
mount -t davfs http:///owncloud/remote.php/dav/files/owncloud/ /mnt/point

but in fstab it wont work:
http:///owncloud/remote.php/dav/files/owncloud/ /mnt/point davfs user,rw,noauto 0 0

I’ve read that I have to type mount /mnt/point to mount the defined folder. Does it mean that I have to insert “mount /mnt/point” anywhere in cron once after booting?

#4

nowadays I would realize this with systemd an not cron (@reboot) or fstab.

e.g.:

  1. https://blog.sleeplessbeastie.eu/2017/09/25/how-to-mount-webdav-share-using-systemd/
  2. https://wiki.archlinux.org/index.php/Davfs2
1 Like
#5
#6

https://wiki.ubuntuusers.de/WebDAV/#Einbinden-mit-Benutzerrechten
translated:
“… it should absolutely be ensured that one takes the option “noauto” in connection with “user”. Otherwise, the system tries to mount the directory at startup, which will not succeed. In the worst case, this means that the operating system will not start at all.”

#7

The option noauto causes the share never to be mounted by the system, only on user request via the mount command. So your observation that “it works manually but not in fstab” is exactly how noauto is supposed to work.

What @fbartels proposes is to use systemd’s automatic mount facility. This means that the share will be mounted automatically each time any software tries to access the mount point, e.g. a simple ls or trying to open a file from there.

This has several advantages:

  1. The user account doesn’t have to resolvable during boot.
  2. The mount attempt is only made when software needs access to the mount point; therefore it isn’t slowing down the boot process.
  3. The remote server doesn’t have to be reachable during the boot process, only when software needs access to the share.
  4. Intermittent network outages (= the remote server not being reachable) can be recovered from nicely as another mount attempt made whenever software accesses the mount point (the fstab variant is only tried once during boot but never again afterwards).

Trying to mount via fstab is simply the wrong tool for the job (like using a screwdriver to drive in a nail). Yes, it can get the job done under certain conditions, but there are better ways (e.g. use a hammer instead of the screwdriver).

1 Like
#8

Agree with @Moritz_Bunkus statement, except for one thing. It was @ThorstenS who recommended systemd. I nearly wanted to highlight why it did not mount at boot time through fstab.

On my own system I still use autofs for this kind of functionality, but if I would start from scratch mounting via systemd seems superior.

#9

Ooops, sorry! Credit where credit’s due, of course.

#10

Thank you very much - these are completely all advantages that I need for my usecase. And I also understand what noauto causes …
=> systemd is the perfect way for me
Thanks to all of you

#11

You seem to be missing some encryption for http://owncloud/, is this on purpose? And last time I tried davfs2 it blocked IO operations on the mounted directory, so even df does not work while a file is being uploaded ( https://savannah.nongnu.org/support/?107064 ).

Mastodon