Note - If you do not fill in every section below, your post won’t be answered - you must provide the steps you have followed so far and the actions you’ve already taken. Make sure to remove this notice from your post too.
Screenshots of text are prohibited. Always copy and paste text as text.
Make sure you search before posting! Duplicate posts for the same issue may not be answered.
OS Name/Version:
Product Name/Version: AMP v2.6.1.6 on Ubuntu Server 24.04.2
Problem Description:
I wanted to use an extra HDD to store my instances on. Therefore, I mounted a disk in Ubuntu using xfs in /etc/fstab. Additionally, I created the folder /amp/instances and changed the owner to “amp:amp” and (for testing) the access rights to 775. After that, I integrate this path under “Datastore” in order to use it.
Now, when I create an instance (game doesn’t matter), it starts the process, switches to status “waiting” and after a short time, it switches to “Offline”. Additionally, a lot of normally created *.kvp files are missing, as if AMP isn’t able to fully install this instance.
Here the output, when I try to start this instance (PORT and IP have been replaced by me):
12:30:11
Running command line: “/usr/bin/docker ps --format {{.Names}}” from “”
Running command line: “/usr/bin/docker pull cubecoders/ampbase” from “”
Using default tag: latest
12:30:12
latest: Pulling from cubecoders/ampbase
Digest: sha256:a18b6bc46f5622ff7572400b6ed3c3630aed4d26326a919873dd83265463e161
Status: Image is up to date for cubecoders/ampbase:latest docker.io/cubecoders/ampbase:latest
Running command line: “/usr/bin/id -u” from “”
Running command line: “/usr/bin/id -g” from “”
Running command line: “/usr/bin/docker run --rm -d --name AMP_mcLV01 -v “/mnt/amp/instances/mcLV01”:/AMP -v “/mnt/amp/instances/mcLV01/.virtualhome”:/home/amp -e AMPUSERID=1001 -e AMPGROUPID=1001 -e AMPHOSTPLATFORM=Linux -e AMP_CONTAINER=1 -e AMP_MOUNTPOINTS=”" --net=host -e AMP_CONTAINER_HOST_NETWORK=1 cubecoders/ampbase +Core.Webserver.Port "[PORT]" +Core.Webserver.IPBinding "[IP]" +Core.AMP.InstanceID "4bfb6d38-5e8c-4e83-aafc-182defafeccb" +Core.Security.MetricsHMAKKey "291fd494-bee0-4c43-8e1b-ed9e1ad4c4be"" from “”
c4fe2a0732ec4bb471ae1b6bc17c4940fa1a2c6e27b077fb182dafb45130f030
Running command line: “/usr/bin/docker ps --format {{.Names}}” from “”
Running command line: “/usr/bin/docker ps --format {{.Names}}” from “”
Alright, first things first. Let’s isolate the issue here. Since you’ve already made sure the disk is mounted and permissions are set correctly (or so it seems), AMP might still be unable to write to the datastore properly. Permissions can be a bit finicky with mounted drives, even if they look correct on the surface.
Let’s see if the amp user actually has proper write access to the mounted drive. Try switching to the amp user first by running:
sudo su -l amp
Once there, navigate to the /mnt/amp/instances/ folder and attempt to create a simple file:
touch testfile && ls -l testfile
If that fails, permissions or ownership need re-checking. Let me know what happens!
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Thanks for the reply.
It seems, the permission is set correctly. The command works without any problems.
I also suspect some sort of permission problem but I can’t pinpoint it exactly.
Alright, if the amp user can write there directly, we know there’s something more interesting at play .
Since it seems docker is being used here, let’s check if your mounted datastore has the right docker permissions set. Docker often has issues with mounted directories due to its strict volume permissions when running containers. The clue is in the logs you provided (“creating instance fails during docker operations”).
Try the following:
Make sure your mounted directory has the necessary SELinux contexts (though SELinux is usually off on Ubuntu, let’s just rule it out):
No worries! Since SELinux isn’t even tagging the files on Ubuntu (expected, since it’s often not used), we’ll just let that part go. Let’s focus on getting Docker’s volume stuff sorted.
Unfortunately, you can’t directly add the :z (or :shared) option in AMP’s GUI without some tweaking unless CubeCoders magically updated something. So instead, humor me and try a workaround:
Check the Datastore in AMP:
Head to your ADS instance (ADS01), and navigate to Datastore.
Confirm the path /mnt/amp/instances is listed there and properly pointing at your mount.
Change Mount Mode via AMP Settings:
What we want is for AMP to tell Docker to apply permissive sharing options for the mounted directory.
However, if AMP doesn’t allow advanced parameters for mounting directly, you might need to tweak ampdaemon.json or introduce wrapper scripts for advanced settings. I’ll dig deeper if needed—let me know!
For now, does AMP itself confirm that “Datastore Integration Resolves /mt/Instances”?
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Checked the Datastore and /mnt/amp/instances appears without issue. I can also “Repair” (doesn’t fix it) or “Calculate Usage”. As some, but not all, necessary files for the instance I create are written, I think, this is ok so far.
Okay, it sounds like AMP recognizes the datastore correctly but maybe Docker’s mount permissions are causing files to be partially written. A classic “It’s fine… BUT IS IT?” moment.
Let’s test another angle—does AMP spit out any more detailed logs about this datastore issue? You can check:
In the AMP GUI:
Right-click on the instance with the issue and select “View Logs.”
Look for entries in there that scream “Permission Denied” or related errors when it tries to create/write files during the setup.
If you don’t see useful info, try AMP’s Diagnostics Tool:
Go to AMP → Support → Diagnostics, and hit the “Copy data to clipboard” button.
Paste what it shows here (no sensitive info like passwords or private keys, though).
Those logs might spill the tea about why Docker is ignoring some files.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
There is no right-click on an instance, this only opens the browser’s context menu. In the “Deployment Log” are no visible errors.
In the Main Menu under “Support and Updates”, when I click on “Copy data to clipboard”, nothing is copied to the clipboard, it’s just empty. Tried it in three different browsers.
The folder AMP_Logs isn’t created in the broken instance. Therefore, no log files for this instance can be read.
There’s also no /opt/cubecoders/amp/logs folder. Only the folders “plugins” and “shared”, as well as “ampinstmgr”, “getamp” and ioredir.so" exist in /opt/cubecoders/amp
Oof, we’re dealing with a “Ghost Instance” situation where it doesn’t even make logs. Spooky.
If the instance isn’t fleshing itself out enough to make a log folder, it points even more toward Docker/Mounted Drive wackiness. Since /opt/cubecoders/amp is missing the normal log path too, your AMP setup might not be fully installed where expected—double spooky.
Alright, let’s get into AMP’s global logs and diagnostics, but here’s another place to poke before escalating:
Check ADS for any global AMP logs:
The instance logs survive in ADS, even when the instance fails.
Open the AMP GUI > Head to your ADS (default: ADS01) > Logs Panel on the left menu.
Look for fresh timestamps at/during that instance startup failure.
Permissions Recheck for ADS + Docker:
Run ampinstmgr fixperms as the main admin/root, NOT via sudo su -l amp. That ensures ADS and Docker tasks have synchronized permissions for all AMP files.
Any output from that command that looks like trouble?
See if either sheds light, and we’ll figure out this time-traveling, logless mess together.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Did run ampinstmgr fixperms and tried starting the instance afterwards. No change and, despite the already posted log information, nothing has changed.
Alright, we’re officially in “What the heck is even happening?” territory. Since everything sensible (and some borderline overthinking stuff) has been checked, we need to cover the basics systematically while diving into Docker-specific issues.
Here’s one last major thing to test: Does this problem occur without Docker in the equation?
Try this:
Create an Instance Without Docker:
Head to the ADS GUI.
Create a new instance like normal but disable the Docker support. You can find this under “Instance Creation” settings when you select your options.
Use the mounted Datastore like before.
If that works, the issue is directly tied to how AMP is interacting with Docker and mounted volumes. We’ll focus there. If it still fails, then the mounted volume is just not cooperating properly with AMP’s file-writing flows.
Let me know what happens so I can tweak the next steps.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
After disabling “Create in Docker Containers” under Configuration → Instance Deployment I tried to create a new instance (mcLV2). The following error occurred and no instance was created:
An error occurred trying to start process ‘/mnt/amp/instances/mcLV201/AMP_Linux_x86_64’ with working directory ‘/mnt/amp/instances/mcLV201’. Permission denied
A-ha! “Permission Denied” strikes again, but now it’s directly calling out /mnt/amp/instances/mcLV201. It seems that, even though permissions look fine initially, something deeper is blocking executable access for AMP in that directory.
Likely Culprit: Mount Options
When you mounted the drive, the filesystem options might not allow AMP to run executables from there. This happens a lot when using noexec or other restrictive mount options.
Let’s check this real quick:
Run:
mount | grep /mnt/amp
Look for the mount options; common ones causing issues are noexec, nodev, or nosuid.
If noexec is listed:
You’ll need to remove it from /etc/fstab and remount the drive.
Edit the /etc/fstab line for your volume to include appropriate options (e.g., replace noexec with defaults or exec):
/dev/yourdisk /mnt/amp xfs defaults 0 0
Then remount:
sudo mount -o remount /mnt/amp
Test Instance Again:
Retry creating the instance after adjusting the mount. Let’s see if that clears the “Permission Denied” hurdle.
If noexec wasn’t the issue, hit me with your current mount options so we can dig deeper.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
All three options were present and I changed it to the mentioned “defaults 0 0” (was “defaults 0 1”)
After that and a re-mount (“systemctl daemon-reload” was necessary, because of changes in fstab), I tried to create a Minecraft as well as a Satisfactory instance. Both could be created and joined successfully.
This solved my problems.
This post was produced by an AI controlled by CubeCoders Limited - 
.
So instead, humor me and try a workaround:
Let’s make this as painless as possible then!
Since everything sensible (and some borderline overthinking stuff) has been checked, we need to cover the basics systematically while diving into Docker-specific issues.
