autofs tries to find .xdg-volume-info and autorun.inf

Hi Thomas,
that isn't part of the autofs code or config.
It is a general procedure mostly but not exclusively of the Desktop integration.

You might remember that back in the days when you inserted a CD it got a Icon and potentially started some installer automatically.
That is what those two files define - for example see [1]

This thread [2] discusses how to disable that in gnome.

I hope these hints help.
IMHO that is not a bug in autofs, but if you really think it is please re-open and explain why you think it is.

[1]: https://mail.gnome.org/archives/gvfs-list/2009-February/msg00024.html
[2]: https://askubuntu.com/questions/791076/disable-external-hard-disk-auto-open-autoplay-at-every-startup

[Expired for autofs (Ubuntu) because there has been no activity for 60 days.]

No, this is a real thing. The issue is valid. The explanation does not dismiss it. Even if the assumption that the desktop is somehow looking for these files for autorun functionality, how does that equate into an entire mount point being generated.

Is this fallback behavior of some kind?

Just as the original example illustrated, the automount daemon completely ignores the map file and attempts to mount these 2 mount points instead. It didn't do that before.

Status changed to 'Confirmed' because the bug affects multiple users.

I have been trying to recreate in different permutations and I have come to the conclusion that the 2 weird mounts aren't the primary issue. Those are strange, but it appears to break when the autofs is started and stopped multiple times as it would be if someone were trying to troubleshoot there configuration.

It appears that the daemon does not clean up when it closes and can sometimes leave open mounts That should be closed. I found that if I stopped the daemon and restart, my configured mounts were not being mounted automatically.

When this happens, the happy path only returns when I close the deamon and manually release any held mounts.

To recreate the error:
1. I ran the daemon in debug mode in the foreground
2. navigated to OR did an "ls" on an automounted mount to verify that it was mounted
2.1 close any open file explorer windows
2.2 cd out of any mounted directories on the command line
3. After confirming the mount, I then manually close the running automount daemon
4. If I restart the automount daemon at this point, it does not consistently re-mount my configured mounts

This is where it is easy to assume that the 2 unconfigured mounts initially reported are the symptoms of the failure. It appears that automount does not cleanly close out in such a way that it can be restarted without manual intervention. This may be known/inherited bugginess of automount, and if so, maybe not a severe issue is being reported here.

Still no explanation for the 2 unconfigured mounts though. That is still valid unexpected behavior, whether the OS has autorun support or now.

Hi, I have the impression we are speaking of different issues here. If we're dealing with more than one bug I think we need to file separate bug reports. I'll try to recap:

1. This bug was originally opened as Thomas Schweikle was surprised by the fact that autofs tries to find .xdg-volume-info and autorun.inf. Christian explained that this is likely done on purpose. Thomas didn't complain about autofs ignoring the map file.

2. brownboyjohn says that the issue is valid and that autofs ignores the map file, and that this didn't happen before. To me it looks like "autofs ignores the map file" is a different issue. If this it the case, it deserves its own bug report, explaining when it did stop working, as far as it is possible to tell.

3. brownboyjohn also notes that the automount daemon leaves stale mounts when stopped. This is yet another issue I think, but before calling it a bug we need to make sure that the mountpoints were not busy when the automount service got stopped. There is no way it can unmount busy mounts I'd say, but I'm not familiar with the package.

Waiting for more information I'm setting this report to Incomplete.

[Expired for autofs (Ubuntu) because there has been no activity for 60 days.]

I made a file auto.extra with:

.hidden /.
NAS -fstype=nfs,vers=4,rw,soft,rsize=8192,wsize=8192 <my server>:/Download

This way autofs is first loading a directory .hidden which is empty, which is on purpose.

Now the errors disappear from autofs. I think this is a simple but fine solution.
In Thunar the folder .hidden is only visible when the option ¨show hidden files¨ is selected.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1437754 for more info over the bug.

Han, thanks for the workaround suggestion. I'm not certain if that resolves the original issue, and as Paride mentioned there seem to be several separate issues identified by commenters so far. But I'll reopen the bug for further investigation. Meanwhile, I would suggest raising these issues upstream, as it sounds like (esp. from the redhat bug report) the issues are general and not just specific to Ubuntu.

Hi, the problem seems to come from gvfs-udisks2-volume-monitor. See upstream: https://gitlab.gnome.org/GNOME/gvfs/-/issues/287

There the problem is clearly stated :

....¨The difference with autofs in comparison with ordinary mounts is that the mount always exists (you can see it in "/etc/mtab"), but do not have to be really mounted. However, gvfs-udisks2-volume-monitor thinks that it is really mounted if the mount exists...
Consequently, the following code is called which looks for some files on that mounts (e.g. autorun.inf, .xdg-volume-info), which causes the unwanted automounts for autofs.¨

But no solution for autofs momentarily, the patch proposed caused other issues.

Status changed to 'Confirmed' because the bug affects multiple users.

Btw, I do not have an issue with that the automount daemon completely ignores the map file.
In the file "auto.extra" I can also put a line with .xdg-volume-info /-
Then the systemd daemon is only mentioning: xubuntu automount[]: the key "autorun.inf" not found in map source(s).

Thanks Han, that makes sense that the issue is actually in the volume monitor's (lack of) handling for autofs' transitory nature. I'll reassign to that package for further investigation.