portainer: Can't update environment variable on Synology NAS DSM7

Bug description When I edit a container to update environment variable, at restart the variable isn’t modified. This occurs only on Synology NAS, DSM 7

Expected behavior Env Variable must be updated within container.

Portainer Logs Nothing in the logs

Steps to reproduce the issue: Open container image Update value image Restart image Still old value image

Technical details:

  • Portainer version: 2.9.0
  • Docker version (managed by Portainer): 20.10.3, build b455053
  • Platform (windows/linux): linux / synology
  • Command used to start Portainer (docker run -p 9443:9443 portainer/portainer): docker run -p 9443:9443 portainer/portainer
  • Browser: Chrome 94
  • Use Case (delete as appropriate): Using Portainer at Home
  • Have you reviewed our technical documentation and knowledge base? Yes

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 15
  • Comments: 51 (7 by maintainers)

Most upvoted comments

Okay, somewhat positive news: I can replicate this behavior on my Synology NAS here. I don’t yet have a solution, but at least we have a starting point!

These guys just don’t care about Synology users, that’s for sure.

I’ve managed to get my hands on a Synology NAS now and will be setting it up to do some testing.

Welcome in 2024 😄 And this bug is still happen… Docker version 20.10.23, build 876964a DSM 7.2.1-69057

Not an elegant solution, but if you create the container initially via the Synology integrated docker management and set the environment variables there, they are successfully saved and stay the same, even after recreating the container via portainer. So you can keep the variables ans configure everything else via portainer…

The workaround that worked for me was to stop the container in Synology DSM, then edit it (ENV is under “Advanced” options) to make the changes you want. Then start the container again. Portainer should show the updated ENV values. Hope this helps.

Just another “same prob here” post. Would be great to get this sorted out.

Can confirm this is still an issue with

  • DSM 7.0.1-42218 Update 2
  • Portainer 2.11.1
  • Docker 20.10.3-1239

Docker compose is also not working especially well in Portainer

awesomeness to all of you - this was clearly much more complicated, but is coming together!

Oh yeah it works nicely now, I used the script @markdumay mentioned above. Also I opened a ticket to Synology to let them know about this.

Same issue here, it took an hour of troubleshooting to see that environment variables defined in a swarm stack are sometimes completely ignored. Seeing it won’t get likely fixed, I’ll try to install the official version of Docker.

The workaround that worked for me was to stop the container in Synology DSM, then edit it (ENV is under “Advanced” options) to make the changes you want. Then start the container again. Portainer should show the updated ENV values. Hope this helps.

This also worked for me.

Has anyone tested this with DSM 7.2 beta and the new “Container Manager” Docker implementation? It’s a pretty major change on Synology’s side and I wonder if it perhaps resolves this issue.

having the same issue here - thought i was going stupid when my variables were not saving/updating when i edited.

for now running every single container through stacks with docker compose files

is there a plan to fix this bug?

long story short, throw away the synology and move on i guess?

I’d rather abandon Portainer than using something else as my Synology - it’s not just Docker I’m running on it. Surveillance Station, Shared Folders, RSYNC Backups to remote machines and much more. The effort to switch that is 10 times higher.

Don’t get me wrong, portainer is a great project and there isn’t much of an alternative - but I cannot understand the dev’s which obviously do not want to support one of the largest docker platforms due to unknown reasons

problem persits … have the same

Sounds like #2423 which seems to indicate this is a long-running issue with Synology’s implementation.

I believe I’m running into the same issue. If it helps, I was originally running the following on a Synology NAS:

  • portainer/portainer-ce:2.6.3
  • pihole/pihole:5.3.1

And now I’ve upgraded to

  • portainer/portainer-ce:2.9.0
  • pihole/pihole:5.3.1

However, I still can’t get pihole/pihole:5.4 or pihole/pihole:2021.10 to work using recreate or duplicate/edit.

The logs will contain errors referencing the now deprecated startup script even if I’ve removed it the edited container. /root/ph_install.sh

This page suggests that a portainer bug wrt keeping around env variables: https://discourse.pi-hole.net/t/pihole-portainer-docker-5-8-1-startup-error/48722/3

Unfortunately, the proposed mitigation step of removing those 6 env variables before saving does not work for me. I’m not entirely sure if it’s a portainer bug or somehow user error because there doesn’t seem to be an explicit way to “save” my removal of env variables. I just make my edits before hitting the “Deploy this container” button.

Newer versions of pi-hole fail on startup, likely due to the following underlying change that was referenced in the post above: https://github.com/pi-hole/docker-pi-hole/commit/5ca1dbf35fa8eff1b9e4d8143f2016a1b0c9eb3b