The new autofs with Fedora 9/10 generates temporary mount-points that don't work well with the path-based configuration in davfs2.conf. Here is a small patch that lets davfs2.conf group options based on source URL.
Carl D. Roth
davfs2.conf parsing patch for use with autofs
It looks not that easy to me.
URLs are not necessarily unique. Different users may want to mount the same resource at different mount points. Some big WebDAV-servers, e.g. GMX, use the same URL for all users and choose the WebDAV repository according to the credtials. So using URLs to identify a davfs2 file system may lead to conflicts, though this should be very rare.
Therefore davfs2 uses the mount point as key, because it is always possible to make the mount point unique (the secrets file allows URLs too, but only for backward compatibility). Though additionally allowing URLs is possible, it would make configuration more complex and configuration errors might pass unnoticed. "applies |= .." enables unintential merging off entries for different mounts.
Additional remark: a patch like this *must* have an according patch for the man pages.
To get a better understanding about the problem an its importance, there are two questions regarding autofs:
- When mount points are not configured and therefore not known, how do users know where to find their files?
Does this version of autofs use temporary mount points *only*, or is it still possible to configure the mountpoint in advance?
Carl D. Roth
The new autofs behavior appears to be as follows:
* mount the resource to a temporary directory in /tmp
* invoke 'mount --move' to move the mount to its final location
Google indicates that this was done for some sort of race condition bugfix in autofs.
Regarding your questions:
> When mount points are not configured and therefore not known, how do
> users know where to find their files?
Autofs runs as root, and all file configuration is done in /etc. For the purposes of davfs, the autofs mount-points (including credentials) are configured statically by the administrator.
A sample autofs mount map for davfs (mounted e.g. under /dav) would look like
dav.example.com -fstype=davfs,rw,nosuid,nodev \
/dav/users/user1 -uid=user1,gid=user1 https\://&/dav/users/user1 \
/dav/users/user2 -uid=user2,gid=user2 https\://&/dav/users/user2
then it should all work as if by magic:
$ ls /dav/dav.example.com/dav/users/user1
> Does this version of autofs use temporary mount points *only*, or is it
> still possible to configure the mountpoint in advance?
Ha ha that is a good question and I'll need to investigate. In addition to all of the reservations you already laid out w.r.t. my patch, now I come to realize that mount.davfs is unhappy when I run 'mount --move'. The behavior is
* first directory access works fine
* second directory access results in "endpoint not connected" which is an artifact of mount.davs having exited with no messages.
I reproduced this as follows:
# mount -t davfs ... https://dav.example.com/... /tmp/mnt
# ls /tmp/mnt
# mount --move /tmp/mnt /tmp/mnt2
# ls /tmp/mnt
# ls /tmp/mnt2
ls: cannot access /tmp/mnt2: Transport endpoint is not connected
Is this a (mis)feature in mount.davfs?
I tried debugging mount.davfs, but I'm not too familiar with the source code flow... What I know is that mount.davfs exits cleanly (status 0). My suspicion is that it calls is_mounted(), which returns false since the automounter changed the mount-point out from under it.
What would be the implications of changing the caching in mount.davfs to *not* include the destination path? Would a cache directory keyed using (host, source path, user) be sufficient?
davfs2 indeed does ot work with "mount --move" because it periodically checks whether it is still mounted with the mount point as key.
The reason for this: the kernel file systems (fuse and coda) do not send any message to the userspace daemon, when a file system is unmounted, so it has to find out another way. A possible way would be to just try a read on the fuse or coda device. This would probably work with fuse, but will not work with coda (the coda device gives the same error EAGAIN when no data are available and when the file system is not mounted).
Another way would be to not check at all, but use the umount helper to send SIGTERM. But the umount helper would need a key to identify which mount.davfs daemon to kill. So we are back with the key again.
I did not find a concise description of the problem. But my assumption:
The mount points of some of the autofs handled files systems are on other autofs handled file systems and may not be available when mounting these file systems in parallel. In this case there is another problem with davfs2. davfs2 needs it's configuration data and its cache directory. This will be in the user's home directory in most cases, but home is one of the first candidates for autofs and might not be there.
You could put all this on the root partition, but this would mean that unprivileged user have to be allowed to edit files in places that are usually only edited by root (they at least must be allowed to edit their secrets file).
mount point as part of the cache directory name:
It is not really necessary, but it would prevent a single user to mount the same URL twice. This is not much of a restriction and would be ok. But it would require measures to avoid doing this (unintenionally) because two mount.davfs daemons writing to the same cache will create a mess. But this point is only relevant if we don't need the mount point as key in all the other cases.
I still think that URLs are not unique. Conflicts surely will be rather rare and it would not be much of a restriction in practice. But on the other hand: not handling davfs2 with autofs is not much of a restriction either.
One way to solve the unique key (other than mount point) requirement would be to use some arbitrary unique string and associate the URL to this key by means of a configuration file. But there is the problem with configuration files on not yet mounted file systems.
To fit davfs2 into autofs would require to change some of the basic design decisions. I do not generally object to this. But when considering different conflicting requirements the main purpose of davfs2 should be taken into account:
- davfs2 is not intended to be a network file system like NFS.
I think the WebDAV protocol is not really suited for this (and davfs2 neither)
- davfs2 aims on the original goal of WebDAV - remote collaborative authoring.
The "file system" is only to make the resources accessible to applications
without built-in support for WebDAV.
Of course it may be used for whatever you want. But there may be conflicts.
For example: from what davfs2 is intended for, a davfs2 file system is
usually a private resource of one user. So not allowing the mount point, the
cache and the configuration in the users home directory is a bad idea.
I closed this item because I see no way to solve it in the near future and the davfs2 project now moved from Sourceforge to Savannah.