Docker Compose Paths to Config Files Unmapped After Update and 7 To 8 Patch Script Run

I backed up my OMV 7x\Debian Bookworm installation using dd, then ran the update to version 8. Everything went smoothly, except for the MDx issue already mentioned in other posts. I was able to resolve that by editing the mdadm files. As part of that troubleshooting I also ran the fix7to8upgrade script. Everything seemed fine, but I didn't really examine the Compose plugin at first, so it may have been malfunctioning then and I didn't catch it. A day or two later I attempted the 2 updates that would get me to OMV version 8.0.4-1 and the omv-compose 8.1.1 update. When I clicked the checkmark button in the yellow banner at the top to apply the changes, I got a 500 error (see the "OMVDeployCompose Jinja Error.txt" attached file).

I tried rebooting and the yellow "Pending Configuration Changes" banner was still there. Applying the changes caused the Jinja error to reappear, and the changes didn't apply. I see that the files will not restore because the storage object is not found, so I understand that is the root of the issue, however I have looked through every storage device (SD card, NVMe drive, USB drive, MD0 RAID 10 array) that was ever connected to that Raspberry Pi 5 and nothing I have has the UUID mentioned in the error message. Going into Services|Compose|Restore and attempting to restore the Global Env file yields this error message, which references the same unknown UUID:

Failed to execute XPath query './/system/fstab/mntent[uuid='a6feeac8-2d57-4414-b4fe-007bf9bd4a57']'.



OMV\Config\DatabaseException: Failed to execute XPath query './/system/fstab/mntent[uuid='a6feeac8-2d57-4414-b4fe-007bf9bd4a57']'. in /usr/share/php/openmediavault/config/database.inc:88

Stack trace:

#0 /usr/share/openmediavault/engined/rpc/sharemgmt.inc(1164): OMV\Config\Database->get()

#1 [internal function]: Engined\Rpc\ShareMgmt->getPath()

#2 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array()

#3 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()

#4 /usr/share/openmediavault/engined/rpc/compose.inc(387): OMV\Rpc\Rpc::call()

#5 /usr/share/openmediavault/engined/rpc/compose.inc(402): OMVRpcServiceCompose->getSharedfolderPathMap()

#6 /usr/share/openmediavault/engined/rpc/compose.inc(462): OMVRpcServiceCompose->resolveSfPlaceholders()

#7 /usr/share/openmediavault/engined/rpc/compose.inc(1086): OMVRpcServiceCompose->renderBody()

#8 /usr/share/openmediavault/engined/rpc/compose.inc(3361): OMVRpcServiceCompose->setGlobalEnv()

#9 [internal function]: OMVRpcServiceCompose->restoreGlobalEnv()

#10 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array()

#11 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()

#12 /usr/sbin/omv-engined(546): OMV\Rpc\Rpc::call()

#13 {main}

Looks like the only way to change this to point to the correct UUID where the GlobalEnv file is stored is via the openmediavault database, which I have no clue how to access or modify. Maybe there is a config file or some Python code I can edit to change to the correct UUID?

I am thinking when I uninstalled and reinstalled the Compose Plugin from the GUI, all the shared folder paths in here went away, but I may be wrong (I remapped them in the screenshot below, but they were all blank earlier):

The Compose Files, Configs, and Services pages are all empty-no configuration files or global environment files in them. I see an entry in the Stats page, and a current image in the Images page. I do see a (purportedly) running container in the containers page:

Nothing shows up in the Volumes or Repos pages either. I still have all the persistent files and configuration files located in their original places (on the main NAS storage array-MD0), but I am considering starting over with the Docker plugin and relocating all those files to the NVMe drive, as recommended in the "OMV8:Docker in OMV" HOWTO.

I suppose the question is: Should I attempt to recover what I had, or start from scratch with a new container and image and new persistent files? I am open to going either route, but I think the underlying issue may make it difficult or impossible either way.

One other thing: Now I see 5 Docker-related updates available:

...but since there are pending configuration changes that will not apply, installing the 5 updates will make things worse, right? At this point I am hoping for any advice you can give me.

Ok. I will take this redo as an opportunity to make the Docker plugin setup better\faster\less complicated. At least I still have all the persistent data\configs\Global Env files. When I first set up the NAS, I was using the Docker Compose HOWTO from version 7, which was hard to follow at best. Kudos for the version 8 HOWTO-looks like it will be much easier to follow!

I removed the Compose plugin again and copied the DockerData folder over to an NVME drive (root filesystem). I still get the OMVDeployCompose Jinja error when I try to re-add the Compose plugin and I get the XPath restore error when I attempt to restore the global.env file from the Restore page in the GUI. I found the UUID the Compose plugin appears to be choking on in the config.xml file:

<sharedfolder>
        <uuid>82920b0f-e2ca-4823-a218-5f6f86f9188b</uuid>
        <name>Retromania</name>
        <comment></comment>
        <mntentref>a6feeac8-2d57-4414-b4fe-007bf9bd4a57</mntentref>
        <reldirpath>/</reldirpath>
        <privileges></privileges>
      </sharedfolder>

That was a USB drive that I had attached at one point to copy some files over to the NAS drive. It has long since been removed. That drive had nothing to do with Docker or Compose. I may be able to find the drive again and name it Retromania and plug it in and mount it if that is all I need to do to eliminate the issue.

More drastic fix idea: Can I delete that section out of the config.xml file and try again. or is there something else I need to change in the config.xml file to resolve the issue? I also see several config.xml.000x files and a Config_Backup folder which has a couple backups from February 2025, if that helps.

Even more drastic fix idea: If I need to purge the entire Docker database and forego trying to import or restore files, I can go that route too. Please reply with the exact command text to do that, if you think it will fix the issue. I attached the error files again, for reference. I think I am getting closer to the solution, but still not totally grasping all the nuances of the code.

Quote from ryecoaaron

I can't explain how the sharedfolder points at it then. The entry won't change automatically. You should be able to edit the sharedfolder disk to stop the error.

The quote above led me to the resolution.

There it is, right under my nose:

I

Retromania was referenced under the File Browser service, which I don't remember setting up:

I cleared it out of File Browser, disabled File Browser, saved, and deleted the Retromania shared folder. I applied the configuration changes and viola!-all the pending configuration changes applied:

The following modules have been updated: avahi, compose, filebrowser, samba, sharedfolders, systemd, task

undefined

The application is running within the container now, with the added bonus of locating it on the NVMe drive, which should speed it up. Thanks ryecoaaron for leading me to the solution, not solving it for me. That makes the lesson stick better and we hopefully both learned a few things! Move this one to completed status!