portainer cant load the container page, stacks that are stopped can no longer restart as "A stack with the name 'xxxx' is already running"

[dnielso5]

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=19 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng' Distro version | Trixie 0 Kernel version | SBC model | bare metal dell optiplex Additional Information (if applicable)

Software title | Portainer Was the software title installed freshly or updated/migrated? Updated to Trixie, then did a reinstalled of portainer from this thread: #7830 Can this issue be replicated on a fresh installation of DietPi? n/a

Steps to reproduce

load Portainer

Expected behaviour

load containers, also if i stop a stack, i am unable to restart it as "A stack with the name 'xxxx' is already running"

Actual behaviour

unable to load the container, or restart stacks

I added the txt file created from: journalctl -u docker

errors.txt

[MichaIng]

Did you run the commands in my last post of https://github.com/MichaIng/DietPi/issues/7830#issuecomment-3587120625 to really update Portainer? I.e. can you verify it is v2.33.5?

[dnielso5]

I copied and pasted the entire thing into the console and ran it.

This is what it displays at the bottom of my webpage:

**

**

[Joulinar]

Can you share the entire log from all the commands

[MichaIng]

I see the new Portainer starting, up, so that part looks good:

Dec 03 14:56:32 dell1 a25d81cda5c6[17856]: 2025/12/03 10:56PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:636 > starting Portainer | build_number=243 go_version=1.24.9 image_tag=2.33.5-linux-amd64 nodejs_version=18.20.8 version=2.33.5 webpack_version=5.88.2 yarn_version=1.22.22
Dec 03 14:56:32 dell1 f875182800ff[17856]: logger=plugin.angulardetectorsprovider.dynamic t=2025-12-03T22:56:32.280208481Z level=info msg="Restored cache from database" duration=400.26µs
Dec 03 14:56:32 dell1 f875182800ff[17856]: logger=settings t=2025-12-03T22:56:32.284863139Z level=info msg="Config overridden from Environment variable" var="GF_DATABASE_HIGH_AVAILABILITY=false"
Dec 03 14:56:32 dell1 a25d81cda5c6[17856]: 2025/12/03 10:56PM INF github.com/portainer/portainer/api/http/server.go:351 > starting HTTP server | bind_address=:9000
Dec 03 14:56:32 dell1 a25d81cda5c6[17856]: 2025/12/03 10:56PM INF github.com/portainer/portainer/api/http/server.go:367 > starting HTTPS server | bind_address=:9443

Maybe stop all your containers, including Portainer once, or do a reboot. Maybe something was lost in a weird state after Docker and Portainer update.

In the logs I see no Portainer error/entry anymore after the new version started up, but Nextcloud AIO is in an endless error loop about the nextcloud-aio-nextcloud hostname. I guess you need to enter your true domain name somewhere, where it still has the (invalid) default. But that seems unrelated, just spams the logs.

[dnielso5]

I restarted the server several times.

these are the commands in my history:

  482  sudo sed --follow-symlinks -i '/"min-api-version":/d' /etc/docker/daemon.json
  483  ## edit, see below! dietpi-software reinstall 185
  484  dietpi-software reinstall 185
  485  # Remove existing container and image, including CE, BE, and old v1, and store image repo in variable to preserve BE instances
  486  container=$(docker container ls -aqf 'ancestor=portainer/portainer' -f 'ancestor=portainer/portainer-ce' -f 'ancestor=portainer/portainer-ee')
  487  [[ $container ]] && G_EXEC docker container rm -f "$container"
  488  read -r image repo < <(docker image ls -af 'reference=portainer/portainer' -f 'reference=portainer/portainer-ce' -f 'reference=portainer/portainer-ee' --format '{{.ID}} {{.Repository}}')
  489  [[ $image ]] && G_EXEC docker image rm "$image"
  490  # Create volume if it does not exist yet
  491  [[ $(docker volume ls -qf 'name=^portainer_data$') ]] || G_EXEC docker volume create portainer_data
  492  # Deploy new Portainer container, migrate v1 to CE and preserve BE
  493  [[ $repo == 'portainer/portainer-ee' ]] || repo='portainer/portainer-ce'
  494  G_EXEC_OUTPUT=1 G_EXEC docker run -d -p '9002:9000' -p '9442:9443' --name=portainer --restart=always -v '/run/docker.sock:/var/run/docker.sock' -v '/etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro' -v 'portainer_data:/data' "$repo"

Not sure how to get the output from when i ran it.

[dnielso5]

In the logs I see no Portainer error/entry anymore after the new version started up, but Nextcloud AIO is in an endless error loop about the nextcloud-aio-nextcloud hostname. I guess you need to enter your true domain name somewhere, where it still has the (invalid) default. But that seems unrelated, just spams the logs.

When i open the stack i see this:

in fact, every stack does not display the containers. The only stack i can see has a container is one i made AFTER this started.

and unused images:

[Joulinar]

Just for clarification, portainer is working but you have issues with some other stacks? So the issue is not with portainer itself but with other containers?

[dnielso5]

Just for clarification, portainer is working but you have issues with some other stacks? So the issue is not with portainer itself but with other containers?

im not sure, normally the stacks look like this in Portainer, this one specifically was made AFTER i started having issues:

Now all stacks that were made BEFORE i had issues look like this:

Also, if i stop a stack, i am unable to restart it as i get this error: "A stack with the name 'xxxx' is already running" as well as the page "xxx.xxx.xxx.xxx/#!/2/docker/containers" loads a blank page

Im not sure that answers your question, i dont know enough about docker/portainer to know what the differences are.

[MichaIng]

I am also no Portainer expert: So stacks are automatically generated when starting containers with Docker Compose, as far as we just tested. And in your case, it seems like the containers got detached from the stacks somehow. Not sure how Portainer detects stacks, but looks like with the update or database migration that info was somehow lost. I mean AFAIK Docker Compose also just creates docker run commands from the YAML, so for the running containers, there should be no info left that would indicate whether it was started via Docker Compose or not.

But you can re-add containers to stacks, also select/change the YAML file path there etc. So if it is important for you to organize containers in stacks (instead of just doing this in the container tab), you can repair them.

If you have a backup, could be also interesting to try replicating the issue, i.e. that Docker + Portainer update leads to empty stacks, and report it to Portainer devs.

[dnielso5]

@MichaIng so, not sure why this worked but I ran this command:

docker volume rm $(docker volume ls -qf dangling=true)

After that I had to re-pull image and redeploy every stack. Now everything is running like it should.

[Joulinar]

You removed all volumes. Usually this results in data loss

[dnielso5]

You removed all volumes. Usually this results in data loss

The only issues I seem to see are nextcloud wanting to redo the initial setup, same with wg-easy. Everything else is still working as it was before.

[MichaIng]

Makes sense that pulling again all images/stacks solved it. A bit radical, but probably easier than re-attaching each container manually to the related stack.

I am glad this solved it for you. Let's hope this was some rare quirk with the containers detached from stacks after the upgrade.

I'll mark this issue as closed then.