Cannot start service cms-db: error while creating mount source path '/opt/xibo/shared/db': mkdir /opt/xibo: read-only file system

[Peter1]

To be completed by the original poster:

CMS Version

2.3.3

Installation Method

Docker from guide https://xibo.org.uk/docs/setup/xibo-cms-with-docker-on-ubuntu-18-04

Operating System

Ubuntu Linux (64-bit) 18.04.4 LTS

Issue

When updating to the latest version of Xibo, I receive the following error when attempting to bring docker up:

> root@aspdis02:/opt/xibo# docker-compose up -d
> xibo_cms-quickchart_1 is up-to-date
> xibo_cms-xmr_1 is up-to-date
> Starting xibo_cms-db_1 ... error
> 
> ERROR: for xibo_cms-db_1  Cannot start service cms-db: error while creating mount source path '/opt/xibo/shared/db': mkdir /opt/xibo: read-only file system
> 
> ERROR: for cms-db  Cannot start service cms-db: error while creating mount source path '/opt/xibo/shared/db': mkdir /opt/xibo: read-only file system
> ERROR: Encountered errors while bringing up the project.

Result of df-h:

> root@aspdis02:/opt/xibo# df -h
>         > Filesystem      Size  Used Avail Use% Mounted on
>     >     udev            1.9G     0  1.9G   0% /dev
>     >     tmpfs           395M  1.2M  394M   1% /run
>     >     /dev/sda2        64G   11G   50G  17% /
>     >     tmpfs           2.0G     0  2.0G   0% /dev/shm
>     >     tmpfs           5.0M     0  5.0M   0% /run/lock
>     >     tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
>     >     /dev/loop0       94M   94M     0 100% /snap/core/8935
>     >     /dev/loop1      121M  121M     0 100% /snap/docker/423
>     >     /dev/loop2       94M   94M     0 100% /snap/core/9066
>     >     tmpfs           395M     0  395M   0% /run/user/1000

> touch /opt/xibo/test = created file
> rm /opt/xibo/test = deleted file


> root@aspdis02:/opt# ls -l
> total 8
> drwx--x--x 4 root root 4096 Mar  2 13:18 containerd
> drwxr-xr-x 3 root root 4096 May 27 11:51 xibo

> root@aspdis02:/opt/xibo# ls -l
> total 84
> -rw-rw-r-- 1 root root  1205 Apr  7 07:58 cms_custom-ports.yml.template
> -rw-rw-r-- 1 root root   874 Apr  7 07:58 cms_remote-mysql.yml
> -rwxrwxr-x 1 root root  3395 May 27 10:34 config.env
> -rw-rw-r-- 1 root root  3415 Apr  7 07:58 config.env.template
> -rw-rw-r-- 1 root root  2231 Apr  7 07:58 config.env.template-remote-mysql
> -rw-rw-r-- 1 root root  1202 Apr  7 07:58 docker-compose.yml
> -rw-rw-r-- 1 root root 34520 Apr  7 07:58 LICENSE
> -rw-rw-r-- 1 root root  2088 Apr  7 07:58 README.md
> drwxrwxr-x 5 root root  4096 May 27 11:54 shared
> -rwxrwxr-x 1 root root 15274 Apr  7 08:59 xibo-docker.tar.gz


>     root@aspdis02:/opt/xibo/shared# ls -l
>     total 12
>     drwxrwxr-x 3 root root 4096 Mar  2 15:45 backup
>     drwxrwxr-x 5 root root 4096 Mar  2 15:29 cms
>     drwxrwxr-x 5  999 root 4096 Mar  2 15:29 db

I used the command:

chown -R root /opt/xibo/shared/db to change the owner of db to root but the error still persists

Can anyone shed some light on this? The permissions look to be there?

Thanks

[alex]

It looks like you’ve installed Docker from the snap store rather than from the Docker repositories.

You need to uninstall the Docker snap and install it using the guide we provide directly from the Docker repository.

[Peter1]

Thanks, removed docker and reinstalled using the following guides:

Install Docker Engine on Ubuntu

Install Docker Compose

When I copy my db into the shared folder I get an error about cms@ip address not allowed access but this was a test install migrating from a windows server install.

Thanks again.

[alex]

You can’t just copy in an existing database.

If you want migrate from a custom install to Docker, then you need to follow the guide here:
https://xibo.org.uk/docs/setup/upgrade-and-switch-to-xibo-for-docker-install

You’ll need to down your containers and delete shared/db before starting.

[Peter1]

@alex

nd delete s

I may of not been clear, i had switched to docker and had users and templates setup. The database i’m trying to copy back was from a working docker install, i started having issues when updating to the latest build.

[alex]

You should still import the database from a mysqldump backup rather than copying in the raw database files.

Copying them in may work if the containers were all stopped/down when you took that backup, but if they were running then it won’t be consistent and you may well encounter issues. You’re always best taking a consistent mysqldump backup - or using one of the ones provided for you.