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

Totally get the user experience end. It’s unfortunate that relative paths do not work in that fashion. The only other thing that you might want to try is making the same edit, but change the version of the file to something much newer, like 3.4 to see if relative paths were added as a feature later. I know it seems like it shouldn’t matter, but Docker is pretty rigid about how compose files are interpreted sometimes.

If that doesn’t work, I’m tapped out.

Actually, I lied. It’s right in the docs

    volumes:
      - type: bind
        source: ./static
        target: /opt/app/static

Ditch global volumes section at the end and it should work!

Edit: Note this is the compose v3 reference.

Hi Alex,

I tried to follow instructions on this thread as I had the same problem (CMS was reset after a proposed update of Docker for Windows). I can still see my files in this folder C:\xibo\xibo-docker\shared\cms\library so I guess we should be able to get back everything.

I checked that my C: drive is still shared in docker UI
And I have an alpha numeric password in config.env

I tried to do :
cd \xibo\xibo-docker
docker-compose down
cd \xibo\xibo-docker
docker-compose stop
docker-compose start

and it gave me:
Starting cms-db … done
Starting cms-xmr … done
Starting cms-web … done
ERROR: No containers to start

And from there, I’m not sure how to start a container. (sorry it was hard to follow everything, I hope I haven’t missed the solution written somewhere else).

I tried to upload my docker-compose config but it wouldn’t let me post more than 2 links…

Thanks for your help!

Good, I’m now able to post you the result of docker ps -a and docker-compose config below. I’ve tried a lot of different things, I hope I didn’t mess with my chances to get back everything. I have taken the xibo-docker folder out of the xibo folder that was at the root because it seems to be the usual way to work.

PS C:\xibo-docker> docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS N AMES e36c1d5490e5 centos “/bin/bash” 24 hours ago Up 24 hours k ind_chatterjee 180fcbd2756c xibosignage/xibo-cms:release_1.8.3 “/entrypoint.sh” 4 months ago Up 47 hours 0.0.0.0:80->80/tcp x ibodocker_cms-web_1 91933300cd6d mysql:5.6 “docker-entrypoint.s…” 4 months ago Up 47 hours 3306/tcp x ibodocker_cms-db_1 ff43ff79e667 xibosignage/xibo-xmr:release_1.8.3 “/entrypoint.sh” 4 months ago Up 47 hours 0.0.0.0:9505->9505/tcp, 50001/tcp x ibodocker_cms-xmr_1

PS C:\xibo-docker> docker-compose config services: cms-db: environment: CMS_SERVER_NAME: cms.example.org CMS_SMTP_FROM_LINE_OVERRIDE: “YES” CMS_SMTP_HOSTNAME: gmail.com CMS_SMTP_PASSWORD: yourpassword CMS_SMTP_REWRITE_DOMAIN: gmail.com CMS_SMTP_SERVER: smtp.gmail.com:587 CMS_SMTP_USERNAME: youraccount@gmail.com CMS_SMTP_USE_STARTTLS: “YES” CMS_SMTP_USE_TLS: “YES” MYSQL_DATABASE: cms MYSQL_PASSWORD: hidden MYSQL_RANDOM_ROOT_PASSWORD: “yes” MYSQL_USER: cms image: mysql:5.6 mem_limit: 1g restart: always volumes: - C:\xibo-docker\shared\db:/var/lib/mysql:rw cms-web: environment: CMS_SERVER_NAME: cms.example.org CMS_SMTP_FROM_LINE_OVERRIDE: “YES” CMS_SMTP_HOSTNAME: gmail.com CMS_SMTP_PASSWORD: yourpassword CMS_SMTP_REWRITE_DOMAIN: gmail.com CMS_SMTP_SERVER: smtp.gmail.com:587 CMS_SMTP_USERNAME: youraccount@gmail.com CMS_SMTP_USE_STARTTLS: “YES” CMS_SMTP_USE_TLS: “YES” MYSQL_PASSWORD: hidden XMR_HOST: cms-xmr image: xibosignage/xibo-cms:release_1.8.3 links: - cms-db:mysql - cms-xmr:50001 mem_limit: 1g ports: - 80:80/tcp restart: always volumes: - C:\xibo-docker\shared\cms\custom:/var/www/cms/custom:rw - C:\xibo-docker\shared\backup:/var/www/backup:rw - C:\xibo-docker\shared\cms\web\theme\custom:/var/www/cms/web/theme/custom:rw - C:\xibo-docker\shared\cms\library:/var/www/cms/library:rw - C:\xibo-docker\shared\cms\web\userscripts:/var/www/cms/web/userscripts:rw cms-xmr: environment: CMS_SERVER_NAME: cms.example.org CMS_SMTP_FROM_LINE_OVERRIDE: “YES” CMS_SMTP_HOSTNAME: gmail.com CMS_SMTP_PASSWORD: yourpassword CMS_SMTP_REWRITE_DOMAIN: gmail.com CMS_SMTP_SERVER: smtp.gmail.com:587 CMS_SMTP_USERNAME: youraccount@gmail.com CMS_SMTP_USE_STARTTLS: “YES” CMS_SMTP_USE_TLS: “YES” MYSQL_PASSWORD: hidden image: xibosignage/xibo-xmr:release_1.8.3 mem_limit: 256m ports: - 9505:9505/tcp restart: always version: ‘2.1’

Thanks :slight_smile:

Well it’s showing that the containers are all running, so is the issue that you aren’t seeing your data? Or that you can’t see the CMS UI?

Your logs suggest that the shared folder is located in C:\xibo-docker\shared

Is that right, because your earlier post shows it in a different location c:\xibo\xibo-docker\shared

Which is correct?

Hi Alex,

First : Thank you so much to take the time to try to help.
Now, I have access to a brand new Xibo interface, clear of all data, no displays configured or media in the library. But I know that I still have everything because I can see my old slides in C:\xibo-docker\shared\cms\library

And yes, everything was at first in c:\xibo\xibo-docker… but I moved everything in c:\xibo-docker… because I thought it might be a difference in my configuration that was affecting the system. So right now it’s in C:\xibo-docker\shared\cms\library

Thanks

PM me TeamViewer details if you can do it now, and I’ll take a quick look. I’m finishing up shortly.

Hi, i’m sorry but i’ve the same problem
when i reboot my machine, all data is removed how can i fix that ?

i tried, docker-compose stop and after docker-compose start but still default password

Driving me crazy too … same issue finally got Xibo working but after reboot of the CMS all settings reverted back to defaults …

I’ve been unsuccessful following the “fix”:

cd:\xibo
docker-compose stop
docker-compose start

I guess for now I’ll need to manually rebuild the CMS and make sure the server is never rebooted?

If your data is there in the shared folder then the above will work.

What I’m seeing occasionally is where people have rebooted the server, and then used the CMS for a period of time, so their data isn’t then in shared as it should be.

They then reboot, and of course the data is then no longer where it was when they do apply the above, as it’s correctly now mapped to the C: drive of the computer.

Please be sure that when you upload a media item, it appears in shared/cms/library as expected.

Hi Alex

Thanks for the reply … I’ve tried uploading some media items (.PDFs) but cannot see them appearing in the Xibo\Shared\CMS\Library … this may be why Xibo isn’t saving the settings. Where would the library files be getting stored if they aren’t in this location? I’ll keep poking around …

Inside the container itself - which isn’t persistent storage - so will be lost when the container is recreated.

Check that you’ve correctly shared the C: drive with Docker, and if it is, try resetting those credentials.

Thanks so much for the assistance Alex … this is an amazing product … very impressed :slight_smile:

I managed to get it working but I ended up rebuilding from scratch by doing:

docker-compose down
log off windows
delete windows user profile (probably didn’t need to do this)
log into windows
start docker and re-share the C drive
docker-compose up -d

All good after this :slight_smile: I can see files appearing in the CMS library folder on the C drive!

Thanks

1 Like

Thanks you so much for saving time and resolved quickly my issue was that my account password has been changed and i cant use my white label theme again and also i cant see my data there. But reading from this thread, i have tried to re share the “c:\xibo” drive and every thing is back thanks to all.

I have come across a potential solution to this and if there’s any volunteers who’d like to test and feedback that would be appreciated.

Assuming you use the standard docker-compose.yml file, copy the following in to a new file docker-compose.override.yml in the same directory.

version: "2.1"

services:
    cms-db:
        restart: "no"
    cms-xmr:
        restart: "no"
    cms-web:
        restart: "no"
    cms-autostart:
        restart: always
        image: shaynesweeney/holdup
        volumes:
            - "./shared/holdup:/test"
            - "/var/run/docker.sock:/var/run/docker.sock"

Now inside your shared folder, create a new folder called holdup. Inside that folder, put any file. There must be at least one file in that directory. You can create a new empty document, or put an image in there, whatever. As long as there’s one file.

Now run docker-compose up -d.

That will recreate all the containers and stop the Xibo ones automatically starting. Now restart the computer. When Docker is run after reboot, only the holdup container will start automatically. If it finds that the shared/holdup directory is empty (ie the volume mount isn’t working properly), then it won’t start the Xibo containers. It will check periodically. Once it sees that there is something in the shared/holdup directory, it knows the volume mount is working and will start any stopped containers inside the Docker system. That’s perfect assuming you’re only running the Xibo containers there.

If you’re using the cms_custom-ports.yml file, then you can copy the above as any file name you like - eg holdup.yml. You then invoke any command involving docker-compose referencing both files

docker-compose -f cms_custom-ports.yml -f holdup.yml up -d
docker-compose -f cms_custom-ports.yml -f holdup.yml down
docker-compose -f cms_custom-ports.yml -f holdup.yml stop
docker-compose -f cms_custom-ports.yml -f holdup.yml start

for example. The other instructions all remain the same

Get this error when running on a Windows 10 PC:

C:\XIBO>docker-compose up -d
xibo_cms-db_1 is up-to-date
xibo_cms-xmr_1 is up-to-date
xibo_cms-web_1 is up-to-date
Creating xibo_cms-autostart_1 … error

ERROR: for xibo_cms-autostart_1 Cannot create container for service cms-autostart: b’Mount denied:\nThe source path “\\var\\run\\docker.sock:/var/run/docker.sock”\nis not a valid Windows path’

ERROR: for cms-autostart Cannot create container for service cms-autostart: b’Mount denied:\nThe source path “\\var\\run\\docker.sock:/var/run/docker.sock”\nis not a valid Windows path’
ERROR: Encountered errors while bringing up the project.

Looks like it’s that. Perhaps the version of Docker I tested on is slightly older.

There’s a workaround documented there. Basically export the following environment variable:

set COMPOSE_CONVERT_WINDOWS_PATHS=1
docker-compose down && Docker-compose up -d

I’m trying the proposed workaround (holdup directory, docker-compose.override.yml). It eventually seems to work (like after a couple of hours), but this seems pretty flaky. What I observe via docker ps is that the shaynesweeney/holdup container restarts every 62 (or so) seconds, until for some reason after several hundreds of those, it works. Why is it every 60 (or so) seconds?

Are there other solutions to getting docker to work right? I tried using Autoit and a script, but had no luck.

Kirby

Sorry, additional detail. Xibo is latest level 1.8.12, docker is latest stable channel, downloaded 3 days ago, appears to be Server Version 18.09.2