I'm guessing your portainer volume changed somehow and it lost your stacks? One way to prevent this, is install portainer with docker-compose.
mkdir portainer
cd portainer
touch docker-compose.yml
nano docker-compose.yml
Paste the following:
version: "2.2"
services:
portainer:
image: portainer/portainer-ce:latest
container_name: portainer
volumes:
- /path/for/portainer:/data
- /var/run/docker.sock:/var/run/docker.sock
ports:
- 8000:8000
- 9000:9000
restart: unless-stoppedCntrl X, then Y, then Enter to save
docker-compose up -d
When it's done, you can log back into portainer. You still won't have your stacks obviously, but if this ever happens again, just redploy the compose file and make sure the :data folder is configured... and you'll be fine. Done this several times
Thanks.
Actually i already have a fix volume path for data in my portainer config. I did not do this via compose but manually in portainer config. Should be exactly the same. The container also actually uses the volume. When manually navigatin into the "_data/compose" subfolder of the portainer volume, the "compose" folder is empty....
monsen what you are doing is different from waht KM0201 suggested. You are using a docker volume and must not write to the underlying directory from cli. Docker manages this volume it is is to be accessed from inside an container only.
Did you remove the docker volume before you updaed? If yes, all your config files in this volume are gone. You can use docker inspect <container_name> to get the config and transform into new stacks.
What do you mean with this sentence?
I did not do this via compose but manually in portainer config.
If you install portainer throug the omv-extras ui it will be set up like you showed.
Ok i understand.
Did you remove the docker volume before you updaed? If yes, all your config files in this volume are gone. You can use
No i did not
What do you mean with this sentence?
If you install portainer throug the omv-extras ui it will be set up like you showed.
Ok I thought i might have done this as i have done many docker configs and i might have forgotten.
Portainer keps the stacks as docker-compose.yml files. You can start a container, mounting al local directory and the portainer_data volume and copy the contenst to your local file system.
I did it like this:;
root@omv:~# mkdir portainer # make directory to copy the files to
root@omv:~# docker run --rm -it -v portainer_data:/portainer -v $(pwd)/portainer:/local ubuntu # spin up a ubuntu container
root@99c71bbae130:/# cp -rp /portainer/* /local/ # copy the file to local
root@99c71bbae130:/# exit # exit the container
exit
root@omv:~#Now all portainer files are in ./portianer in the host.
But doing a normal upgrade should not delete the portainer_data volume. Did you move the docker directory during the upgrade?
Couldn't i just navigate to the portainer_data folder on CLI and copy the contents from there?
I have just checked the "compose" folder under there and it also is empty. So seems like these are stored elsewhere.
But doing a normal upgrade should not delete the portainer_data volume. Did you move the docker directory during the upgrade?
No. I did not move anything. The stacks were gone after the update. Nothing done on my end.
On a side note: I don't think the portainer_data folder has been deleted. Something else happened. Everything else is there and active. The containers that are part of the stack are up and running with correct config.
The docker-compose.yml files are only "configuration files" teling docker how to create docker containers. The state of running containers is stored by docker itself. If you shut down docker and restart, it will restart the containers which were running when you shut down the daemon.
This is what you see.
You can not directly copy the files from the directory you found, but can cut and paste the commands I gave above, one at a time.
The command starts an ephermal continer and gets you direcly into a bash shell inside the container.
The rest is obvious, just copying files and then leaving the container (wich stops, destroies and removes the container --rm flag)
Yes, the above is a 1:1 transcript from my shell window.
Don’t have an account yet? Register yourself now and be a part of our community!
