Data without a named volume does not work

[dashohoxha]

It does not work if we don't use a named value for the data, for example like this:

# volumes:
#   data: {}
. . . . .
    volumes:
      - ./data:/data

[mtneug]

Have you created ./data beforehand? If I remember correctly, Docker will create a file instead of a directory which will obviously fail. Bind-mounting directories definitively works. We use it in production.

[dashohoxha]

Have you created ./data beforehand? If I remember correctly, Docker will create a file instead of a directory which will obviously fail.

This is not an issue. The same thing works for ./db without creating a directory: https://github.com/opencast/opencast-docker/blob/9d8632cca0ad3fea1d9b23a248307c7021205aaa/docker-compose/docker-compose.allinone.mariadb.ssl.yml#L34

Docker-compose does not complain when trying to mount a data directory (with - ./data:/data), everything goes well, and the directory is mounted. The problem is that somehow the directory remains empty and the system is broken.

From my experience, this can happen for example when the mounted directory needs to have certain ownership (different from root) and the docker scripts fail to initialize it correctly.

[jojoob]

From my experience, this can happen for example when the mounted directory needs to have certain ownership (different from root) and the docker scripts fail to initialize it correctly.

I can confirm that this is the case. The scripts run with the 'opencast' user (UID 800). When the directory does not exist on the host docker will create one but obviously not with the correct permissions/owner. Somewhere in the logs one can find org.osgi.service.component.ComponentException: /data/opencast/staticfiles does not exists and could not be created

To solve this, just create the directory on the host system in advance with correct owner and permissions.

[dashohoxha]

To solve this, just create the directory on the host system in advance with correct owner and permissions.

In my opinion, this is a workaround, not a solution. The solution would be to fix the scripts to handle this case properly.

[mtneug]

The MySQL/MariaDB images handle this by iterating through every file in the data directory and changing the owner where needed. I think the Opencast images have done similarly in the past and the build image is doing the same even now. The problem is that the Opencast data directory can contain hundreds of thousands of files and even a simple iteration of every file can take minutes/hours, even worse if you use the recommended network filesystem.

What can be implemented, however, is that the permissions of the root folder are set correctly. Since container orchestrators like Kubernetes typically do that for you, this is currently not implemented.