Comment 8 for bug 1908638

>> Is "checkmounted" a standard / API function somewhere?

> No, that would be a new option to be added.

Are you thinking of an xml config option? e.g.:

<volume ... checkmounted="1" ... />

If so, another option like "ignoresource" might be useful. I'm thinking something like:

checkmounted="0/1/true/false"
    When 1/true: don't make mount attempt if volume is already mounted
    When 0/false: attempt mount without checking if already mounted
    Default: 1/true
ignoresource="0/1/true/false"
    (Only evaluated when checkmounted=1/true)
    When 1/true: only require mountpoint to be already used
    When 0/false: require both mountpoint and source to match
    Default: 0/false

>> I'm not seeing how the path gets to be unpredictable (at least for NFS on the linked bug). It looks more like vpt->volume might be failing to match the source path in pmt_utabent_matches as a result of certain xml configs because it's using the content of the path element verbatim instead of constructing it from multiple elements (e.g. 'path="nfs:/home/prisoners/p"' vs. 'server="nfs" path="/home/prisoners/p"') as happens in pmt_vol_to_dev.

> Interesting, I was not aware of this function. Still there could be other functions applied. for example I have path="/dev/disk/by-label/home" which is passed to mount.crypt and transformed to /dev/mapper/_dev_nvme0n1p3 in the mount output. This is done in dmc_crypto_name but it could be a function outside of pam_mount as well.

After more looking around, it looks like pam_utabent_matches really ought to be using vpt->combopath instead of vpt->volume since it is being set reliably in mount_op and defaults to being a copy of vpt->volume. I have submitted a merge request with pam_mount upstream for this.