On Tue, 2019-01-29 at 17:04 +0100, Frank Thommen wrote: > Dear all, > > we mount our homedirectories with wildcard mounts from /etc/auto.home: > > ------------- > * -fstype=nfs,vers=4.0,sec=sys server:/export/home/& > ------------- > > unfortunately due to this > [https://bugzilla.redhat.com/show_bug.cgi?id=1437754] issue and badly > programmed software, there are too many error messages related to failed > mount requests (/home/.hidden, /home/images, /home/srv ecc. ecc.) in the > server logs. I'm aware of this, on the cc of the bug. > > Is there a way to exclude specific keys from the wildcard list? I tried > > ------------- > .hidden :/dev/null > src :/dev/null > * -fstype=nfs,vers=4.0,sec=sys server:/export/home/& > ------------- > > but that generated too many errors on the client side. I wonder if > there is an "official" way to exclude such invalid entries. There's not, the wildcard key match has always matched anything. A blacklist implementation would still need some way to specify its use on the master map entry and that would be non-standard and lead to parse failures on non-Linux platforms and older versions of autofs. And a global blacklist I think would prove to be too general leading to false positives. But your suggestion has merit. I could treat /dev/null local mounts (ie. : escaped ones) as no-op mounts and just return success without performing the mount. I don't recall any cases where /dev/null can be used in an actual mount and the colon escaped location significantly restricts possible cases that I'm not aware of. That wouldn't require syntax that would break existing configs and would simply continue to generate errors for older version of autofs and non-Linux clients. But it would mean the exclusions would need to be listed manually within the each map although I think the specific case we are talking about should only need several commonly use key names that form the bulk of the noise. This would need to be accompanied by a configuration option to make it an optional buy-in and it would need to be set to no by default to maintain the existing behaviour. Wouldn't that help your case? Would it be sufficient (although I'm not sure we have any other options)? Does anyone else have any thoughts or suggestions? Ian
