Default Mount Bindings - Setting does not apply

[TABLE272]

Operating System

Ubuntu 22.04 LTS

AMP Version and Build Date

2.6.0.2 - 20241030.1

AMP Release Stream

Mainline

I confirm that

• I have searched for an existing bug report for this issue.
• I am using the latest available version of AMP.
• my operating system is up-to-date.

Intended Action

Apply default mount bindings for instances running in docker, rather than having to edit CustomMountBindings in instances.json directly.

Expected Behaviour

Mount bind paths provided should be used to add custom volume binds on newly created instances running in docker.

Actual Behaviour

Bindings input aren't being applied. The CustomMountBinds entry for the instance in instances.json isn't updated, and running docker inspect against the container created by AMP does not list these extra volumes.

Reproduction

This has been the case since the feature was added to the web interface, was initially a frequent support topic but died down over time and doesn't appear it was formalised as a GHI at the time.

In my case, I have provided a simple 1:1 host path to container path mapping. Currently mapping Host Path "/home/amp/storage/AMPBackups/{{InstanceName}}" to Container Path "/home/amp/storage/AMPBackups/{{InstanceName}}" under Default Mount Bindings.

When I create a new instance, ensuring Create in Docker Containers is enabled, this should then create the new instances and apply this docker volume bind. Presumably this is intended to modify the existing CustomMountBinds setting in instances.json.

However this does not occur. CustomMountBinds for the new instance remains a blank value, with no custom volume binds applied to the newly created instance if the docker container is inspected.
Manually editing CustomMountBinds in instances.json to provide this same binding still works as intended.

I've attempted a few different paths, to ensure it wasn't an issue with template substitution when attempting to save the value, but simple paths or paths outside of the /home/amp directory (to ensure it wasn't user related weirdness) had the same result.