Answer from the author of hylafax: This stems from attempts to address CVE-2020-15397. See: https://nvd.nist.gov/vuln/detail/CVE-2020-15397 The various commits that were undertaken to address this are: https://sourceforge.net/p/hylafax/HylaFAX+/2534/ https://sourceforge.net/p/hylafax/HylaFAX+/2557/ https://sourceforge.net/p/hylafax/HylaFAX+/2569/ https://sourceforge.net/p/hylafax/HylaFAX+/2574/ Basically the issue is that setup.cache and setup.modem get included/invoked by both root and the fax user (often "uucp"), and we need to ensure that if the fax user gets compromised and rewrites /var/spool/hylafax/etc/setup.(cache|modem) that any use by root will not be affected. The use of a hard link facilitates the necessary security since root uses setup.cache in DIR_LIBDATA and the fax user uses setup.cache in /var/spool/hylafax/etc. If the fax user rewrites its copy then it necessarily breaks the hard link and root will not be using the compromised version. A soft link will probably function adequately most of the time - and appears to be the only solution for systems where DIR_LIBDATA is on a different filesystem from /var/spool/hylafax/etc. However, soft links will not function for the rare instances (client use) where for some reason hfaxd-client operating in a chroot jail needs to include/invoke setup.(cache|modem). I've now addressed this matter here which should prevent other reports of this in the future (yours was not the first, unfortunately): https://sourceforge.net/p/hylafax/HylaFAX+/2647/ In case you're interested in other similar issues that were raised at the same time as CVE-2020-15397 see: https://sourceforge.net/p/hylafax/HylaFAX+/2551/ https://sourceforge.net/p/hylafax/HylaFAX+/2552/ https://sourceforge.net/p/hylafax/HylaFAX+/2553/ There is also another somewhat similar issue that I'll be looking at addressing soon: https://bugzilla.redhat.com/show_bug.cgi?id=2008654