When umounting a davfs2, the pid-file in
/var/run/mount.davfs is NOT deleted after
an otherwise successful umount, which causes the next attempt to mount the same filesystem to fail. This occurs with (u)mount.davfs as well as with (u)mount -t davfs.

To reproduce:
1.
mount -t davfs \
-o _netdev,noauto,noexec,nosuid,nodev,username=<user> <davfs-url> <mountpoint>
2. after successful mount
umount <mount-point>

Then, after waiting for outstanding IO-ops this will exit with status 0.
BUT it will leave the pid-file
/var/run/mount.davfs/<user>-<fs>.pid
behind.

That causes the next mount of the same device to fail with:
---
mount.davfs: found PID file /var/run/mount.davfs/<user>-<fs>.pid.
Either <mount-point> is used by another process,
or another mount process ended irregular
---

Of course the process shown in the pid-file has terminated, so after verifying that, one can safely remove the pid-file as a work-around.

I experience this with kernel
Linux server2 6.12.45-v7+ #1903 SMP Fri Sep  5 14:12:37 BST 2025 armv7l GNU/Linux

on my raspberry pi 3b running up to date
Raspbian GNU/Linux trixie

Expected behaviour:
Remove the pid-file when umounted successful.

PS.: This is my first bug-report, so I apologize in advance, if it does not meet the standards.

Regards
Benno

control: tags -1 +unreproducible

Hello,

I could not reproduce the bug (on trixie, version 1.7.1-1),
neither as root, nor as a regular user belonging to davfs2 group,
with the steps you mention.

The PID file is correctly deleted after umount <mountpoint>
returns.

The removal of the PID file is done in the main mount.davfs2 (line
367 of mount_davfs.c). It is not conditional on anything. The only
reason I could see for the non-removal of the PID file is if the
process running mount.davfs2 is stopped with a signal like
SIGKILL.

Best,

Aymeric