Where is "Disks" information stored and how to modify manually from shell when the web admin will not allow deletion?

I'm trying to do some system maintenance before upgrading to OMV 6 from 5 and I'm seeing a problem where it is listing a storage device that's no longer present:

When I select it no options to perform functions are available. No Mount, no Unmount, no Delete button functionality are active - all disabled.

How would I go about removing this in some manual manner from the shell?

In addition, I've tried twice to add a USB external drive that it does detect and I can seemingly format to XFS, but it simply never shows up here in this File Systems list. So I'm thinking maybe I need to check the manual options out to see if there are some problems going on there and if fixing the ZFS drive showing up when it's not supposed to it might fix the other issue too.

Thanks geaves I had the same thought but couldn't find anything therein that lines up with this. There are shares, but none of them are missing or would be what this could be as they're all mapped to an existing share. Is there a way to map this more directly in some other way to find out where the problem may be?

Hmmm, this just isn't making any sense. The only ZFS volumes I have on the system are the 6 drives formatted with ZFS that are part of the mergerfs filesystem named "tank" so in "Shared Folder In Use" as you asked me to try geaves shows:

And all shares are on the "tank" tank and nothing else.

It seems that I necessarily need an additional method to track this filesystem down that's showing as "missing" since there should be nothing missing it would seem.

In this case I used ZFS as the base filesystem - I did not create a singular RAIDZ pool, but instead 6 individual ZFS drives/volumes that I then incorporated into a MergerFS + SnapRAID arrangement instead of using EXT4 or XFS, etc. I did this because, as noted elsewhere, there are some additional advantages from ZFS of compression.

Each drive is/has its own zpool, yes. and was created via

sgdisk --zap-all /dev/disk/by-id/ata-MFG_MODEL-NUM_SERIAL
sgdisk --new=1:1M:-8M --typecode=1:BF01 /dev/disk/by-id/ata-MFG_MODEL-NUM_SERIAL
zpool create -f -d -m /mnt/tank_drives/bay_1 -o ashift=12 -o feature@zstd_compress=enabled -O casesensitivity=insensitive -O atime=off -O normalization=formD bay_1-MFG_MODEL-NUM_SERIAL /dev/disk/by-id/ata-MFG_MODEL-NUM_SERIAL-part
# etc...

These are all part of the tank in Storage → Union Filesystems:

Then of course it seems we've circled back to the initial illustration under Storage → File Systems:

Thank you very much. This is very interesting in terms of being referenced to the config file at /etc/openmediavault/config.xml. Thank you... It seems as if most entries (likely all) are sane there... Am I correct in that I'm supposed to be looking at the <fstab>...</fstab> dictionary entry section here and no other areas? I am guessing that the "Storage → File Systems" corresponds to the fstab section since there are many "mntent" keys throughout the entire file...

If I'm wrong, please point me to the correct section and I'll dig in deeper there since I'm baffled so far in that I'm not seeing a bad actor here yet.

geaves you certainly are welcome to share yours, thanks. I think the real issue here is that I'm not using any of the ZFS zpools directly since they are all mapped to the MergerFS primary tank volume and therefore would not and do not need to actually be mapped within the fstab. This is how it worked without a problem over the past nearly two years. I just am not sure when this odd issue arose with it showing as it does within the web admin UI.

No raulfg3, this cannot be recreated as it is too large and has been in use as a critical infrastructural piece now for a long time. There are really no actual functional problems per se. The only thing that needs to be done is to A) fix this weird issue that doesn't seem to be actually causing a problem, but is annoying/worrisome and B) add an additional parity drive to the system such that SnapRAID has two drives vs one to secure the data. The third thing - and what I was thinking about doing first - is upgrading the system to OMV 6 to see if that would resolve or improve any of these and simply make sure I'm running on an up-to-date system that might help in any way.

Thank you - I'll see what I can do then about working through an upgrade to OMV 6 before continuing on this.