Docker for Windows: CMS is reset when I restart the host server

Ok, just did it and everything is OK…my layout is still there and also the password.

Microsoft Windows [Version 10.0.14393]
© 2016 Microsoft Corporation. Todos os direitos reservados.

C:\WINDOWS\system32>cd…

C:\Windows>cd…

C:>cd xibo-docker

C:\xibo-docker>docker-compose stop
Stopping xibodocker_cms-web_1 … done
Stopping xibodocker_cms-db_1 … done
Stopping xibodocker_cms-xmr_1 … done

C:\xibo-docker>docker-compose start
Starting cms-db … done
Starting cms-xmr … done
Starting cms-web … done

C:\xibo-docker>

So stop/start is all that happens when you restart the machine, unless you’re running some other commands manually either before or after you reboot the machine?

no, no other commands, just restart the machine.
I now tried to mount the container in a new user with admin rights but the result is the same after reboot…everithing´s gone

I’m afraid I don’t know in that case.

You might get some assistance from the Docker forums instead - as they may know why your data isn’t persisting.

I’ve tried it here over and over and nothing I do replicates the issue you’re having.

Alex,
I´m looking at docker and here´s something I might be doing wrong: do we run Windows or Linux containers?
now I´m running Linux container and if I try to mount the cms in Windows container I always get the message:

C:\Users\administrator\Documents\xibo-docker>docker-compose up -d
ERROR: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version

You could try changing the top version line in the docker-compose.yml file to read

version: "2.1"

There’s a bug here which looks like it might relate:

If that works, I can build that in to the next release without issue.

already tried that, now i´m getting the error:

C:\Users\administrator\Documents\xibo-docker>docker-compose up
Creating network “xibodocker_default” with the default driver
ERROR: HNS failed with error : O parâmetro está incorreto.

C:\Users\administrator\Documents\xibo-docker>

I think you need to ask on the Docker community forum and see if they know why you’re having a problem. It’s beyond my knowledge I’m afraid.

I’d be very surprised if you wanted a Windows container though to run a Linux container image…

I’ve done a fresh install of Docker for Windows (as opposed to Docker Toolbox) and have managed to replicate this.

I’ll have a poke about here too and see if I can figure out what the issue is.

So here’s what I’ve found so far.

If I start fresh, then bring the system up (docker-compose up -d), then the volumes are created properly and data I add to the CMS gets written to the database (and on the to local filesystem) as expected.

If I then stop/start the containers, everything persists as it should (docker-compose stop, docker-compose start)

If I down/up the containers, everything persists as it should (docker-compose down, docker-compose up).

If I then reboot the machine, the volumes are no longer correctly mounted and my changes in the CMS are gone. If at that point I down the containers and bring them back up (docker-compose down, docker-compose up), my changes are restored.

When the containers are working as expected, I see a cifs mount within the container to //10.0.75.1/C => /var/lib/mysql which is not there after a restart.

So it appears there’s some issue with Docker for Windows and resuming containers with volume mounts. I’ll see if I can understand what the issue is some more.

If I prevent the containers starting automatically when Docker starts, then the volumes get mounted as expected when the containers are manually started. For the sake of clarity or others reading this, it applies only to Docker for Windows. Linux Docker installs do not have this issue!

So:

docker update --restart on-failure xibodocker_cms-web_1
docker update --restart on-failure xibodocker_cms-db_1

Then when you restart the machine, you’ll need to open PowerShell and manually start the containers

cd \xibo-docker
docker-compose start

I presume it’s a race condition whereby the host machine’s shared networking isn’t available at the time Docker starts the containers, so the mount fails, the existing data isn’t there, and so internally the container generates a fresh install, which is then lost when that container is destroyed.

I’d imagine there’s a bug for the Docker project in that.

1 Like

I’ve logged it here:

Thank you alex.
now i have another issue but i will open a new post.

Hi Alex,

I had exact the same problem! Now it is fixed after the solution you gave. But… when I restart the CMS server (also windows 10 64X) not only the settings from the CMS are reset, but also the library is empty after a reboot.

Also when I implement your docker changes:

after I manually start Xibo the library is still empty and all my contents are replaced for a red cross.

You say you have this issue, and that it’s resolved, but then you go on to say that it isn’t. So I’m really not sure what the issue is?

On Docker for Windows, you need to manually restart the containers after every reboot of the server, to allow the volumes to be correctly mounted, and hence your content to be available.

Is that working for you? If so, all you need to do is manually restart those containers after a reboot, or from a scheduled task that fires after the machine has been running for a few minutes.

The settings from CMS aren’t default after I restart because of the solution you gave (restarting the containers). so the problem with the settings are resolved. the problem is that the saved files in the library are gone after a restart and they don’t come back after manually restarting the containers. If I go to media after a reboot, the filenames are visible but the thumbnails are replaced for a red cross.

When I try to download a item I see this NOT FOUND screen. So it looks like the file details are still there but the files itself (from the library) are deleted after a reboot.

Nothing is deleted when you reboot the server.

The reason this is an issue is because on Windows, Docker connects to the Windows filesystem in a way that means that when the computer very first starts up, the connection can’t be made, and so containers that start automatically loose access to the parts of them that are persisted on the Windows disk.

Restarting the container restores that link.

So, given the symptoms you describe, find an item in the library which has the cross icon, and note it’s media ID.

Then look on your Windows machine, in the “shared/cms/library” folder. Is there a file there with that ID name?

So for example, if you looked at an image that had ID 40, the file might be called 40.jpg

Let me add to the mayhem

I ma having the same issues. When I reboot it wipes out all me config and data. I have tried all the steps in this and other threads, but I get this:

PS C:\xibo\xibo-docker> docker-compose up
Starting xibodocker_cms-xmr_1 …
xibodocker_cms-db_1 is up-to-date
Starting xibodocker_cms-xmr_1 … error

ERROR: for xibodocker_cms-xmr_1 Cannot start service cms-xmr: driver failed programming external connectivity on endpoint xibodocker_cms-xmr_1 (9dee9f21ba5f70e627927aa5e5bdc3b5b202e07bf7667a9b83d4319ea6defe9a)
: Bind for 0.0.0.0:9505 failed: port is already allocated

ERROR: for cms-xmr Cannot start service cms-xmr: driver failed programming external connectivity on endpoint xibodocker_cms-xmr_1 (9dee9f21ba5f70e627927aa5e5bdc3b5b202e07bf7667a9b83d4319ea6defe9a): Bind for 0.
0.0.0:9505 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

This was working well, until I got a notice that Docker had an update.

Any more ideas?

What you need to do is described in the manual here:
https://xibo.org.uk/manual-tempel/en/install_docker_win10_64bit.html#special_considerations

The error you’re getting “port is already allocated” suggests something else is running using that port already. The “up” command shouldn’t cause that error, even though it isn’t what you need to do in that scenario, so I suspect you may actually have multiple sets of containers there, further confusing the situation.

What does the output of docker ps -a show?

PS C:\xibo\xibo-docker> docker ps -a
CONTAINER ID IMAGE COMMAND
CREATED STATUS PORTS
NAMES
e02aa58fd21a mysql:5.6
“docker-entrypoint…” 16 hours ago Up 15 hours 3306/tcp
xibodocker_cms-db_1
b922c87310ee xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh”
16 hours ago Created
xibodocker_cms-xmr_1
96fe4978393f xibosignage/xibo-cms:release_1.8.2 “/entrypoint.sh”
2 days ago Up 15 hours 0.0.0.0:80->80/tcp
xibo_cms-web_1
73a020adf5b6 mysql:5.6
“docker-entrypoint…” 2 days ago Up 15 hours 3306/tcp
xibo_cms-db_1
105ff30aa271 xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh”
2 days ago Up 15 hours 0.0.0.0:9505->9505/tcp,
50001/tcp xibo_cms-xmr_1
PS C:\xibo\xibo-docker>