Can mount on /mnt but not on other mount point, why?

this is an RHEL8 VM. I'm trying to mount a logical volume on /var (because I need more space). For now I have created a directory /xvar to mount on, but it doesn't work and doesn't show an error. Below an example, I first mount on /mnt, check that it's there, then umount (check again), then try and mount on /xvar. Below that is a listing of SELinux contexts (somewhat of a mystery to me) but I set the context for /xvar the same as for /mnt.

Using mount -v doesn't give any additional hints except some SELinux blurb about the filesystem not having any labels, which I deal with later. No difference between /mnt and /xvar.

~ ls /dev/mapper | grep lvol0
data-lvol0
~ mount /dev/mapper/data-lvol0 /mnt
~ mount | grep lvol0
/dev/mapper/data-lvol0 on /mnt type ext4 (rw,relatime,seclabel)
~ umount /mnt
~ mount | grep lvol0
~ mount /dev/mapper/data-lvol0 /xvar # no error
~ mount | grep lvol0                 # but not mounted, either
~ ls -Zl  / | grep mnt\\\|var
drwxr-xr-x.   2 root root system_u:object_r:mnt_t:s0            6 Jun 21  2021 media
drwxr-xr-x.   2 root root system_u:object_r:mnt_t:s0            6 Jun 21  2021 mnt
drwxr-xr-x.  46 root root system_u:object_r:var_run_t:s0     1360 May  9 14:50 run
drwxr-xr-x.   2 root root system_u:object_r:var_t:s0            6 Jun 21  2021 srv
drwxr-xr-x.  22 root root system_u:object_r:var_t:s0         4096 May  9 14:47 var
drwxr-xr-x.   2 root root system_u:object_r:mnt_t:s0            6 May  9 14:42 xvar

~

[EDIT]

Here's some more shell screencap following tips from Peter Whittaker (below). Upshot:

1. Both /mnt and /xvar are on the same FS
2. It doesn't have anything to do with SELinux.

This is wildly puzzling. I've been using various flavours of Linux and Unix for about 30 years now, and I've never been able to not mount anything anywhere, let alone "mount" explicitly saying it did something when in fact it did not.

# df /mnt /xvar
Filesystem              1K-blocks   Used Available Use% Mounted on
/dev/mapper/rootvg-root   9758720 148816   9609904   2% /
/dev/mapper/rootvg-root   9758720 148816   9609904   2% /
# ts=$(date +%H:%m)
# mount /dev/mapper/data-lvol0 /xvar
# ausearch -m avc -m useravc -ts $ts | tee raw | audit2allow > rules
Valid message types are: ALL USER LOGIN [... lots more stuff ...]
Nothing to do
# cat rules
# mount | grep xvar
# getenforce
Enforcing
# setenforce permissive
# getenforce
Permissive
# mount /dev/mapper/data-lvol0 /xvar
# mount | grep lvol0
# mount -v /dev/mapper/data-lvol0 /xvar
mount: /dev/mapper/data-lvol0 mounted on /xvar.
# mount | grep lvol0
# mount -v /dev/mapper/data-lvol0 /mnt
mount: /dev/mapper/data-lvol0 mounted on /mnt.
# mount | grep lvol0
/dev/mapper/data-lvol0 on /mnt type ext4 (rw,relatime,seclabel)

One word on context: This is a RHEL8 VMWare guest in my company's intranet that I ssh into. I have no access to the machine except ssh in multi-user mode, so no rescue / kernel command line stuff (even if it were possible, with some trickery, messing it up and making the system unbootable would require considertalble social and political hassle with IT which I'd like to avoid at all cost).

Answering as I lack the rep to comment. A few things come to mind:

• what does df /mnt /xvar show? Are they both in fact on /?
• Is SELinux running permissive or enforcing? (getenforce will tell you that) If permissive, it isn't likely to be an SELinux issue.
• If enforcing and /usr/sbin/ausearch and `/usr/bin/audit2allow are available, try something like this:

ts=$(date +%H:%m)
do the mount command that fails
sudo ausearch -m avc -m useravc -ts $ts | tee raw | audit2allow > rules

• that may at least let you know what specific SELinux permissions might be at play: The "rules" file will contain suggested SELinux changes, the "raw" file will have more context to allow for meaningful evaluation of those rule suggestions (never take what audit2allow suggests without review; sometimes SEL is doing exactly what you want...).

I think I found the cause. When I started tinkering with this, I put a mount on /xvar into /etc/fstab with option nofail. At that time, something else may have been not right so that the mount failed but the kernel must still have had a special place in its heart for /xvar (although I had commented out that line in fstab during my further explorations and all examples I gave here). After a clean reboot with the /xvar mount still commented out, I can mount onto /xvar just fine. The fact that "mount" claims to have done the mount without error when in fact it hasn't is a pretty serious bug IMO.

Next steps:

1. Uncomment /xvar mount in /etc/fstab

2. If mounted OK, copy content of /var into /xvar

3. Use mount point /var in fstab (the original plan)