Docker: fail to perisist data / access existing data

Plone Support
1

Hi,
I try to get an old Plone 4.3 site running in Docker. I tried several ways to mount the data into the container, but fail. Following Data — Plone Documentation v5.2, here is what I do:

cp -r ~/plone4.3-backup/zeocluster/var/filestorage/ data
cp -r ~/plone4.3-backup/zeocluster/var/blobstorage/ data
chmod -R g+rwX data/
rm data/filestorage/Data.fs.lock
docker run -p 8080:8080 -v $PWD/data/filestorage:/data/filestorage  \
        -v $PWD/data/blobstorage:/data/blobstorage    plone:4.3 fg

this fails with

IOError: [Errno 13] Permission denied: '/data/filestorage/Data.fs.lock'

What I'm doing wrong?

2

Which user owns that file?

3

The fies does not exist at all. I romoved it in line 3 of the shell commands shown.
On the host, the directory is owned by me and permissions are ug=rwx.
In the container it is own by my host-uid (not by user „plone“).

I was able to work around this by — in the container —

  • adding a group having the gid of the host-users primary group (the one owing the storage directories)
  • adding this gid to the user plone
    then commiting the container and running it.

Anyhow, this is quite clumsy and required to know the host user's gid when building the container. So I would appreciate another solution.

For the records, here are the commands I used:

  1. start a shell in the container
    docker run -p 8080:8080 -v $PWD/data/filestorage:/data/filestorage  \
     -v $PWD/data/blobstorage:/data/blobstorage  \
 --entrypoint /bin/bash -it \
 plone:4.3
  2. in the container
    GID=$(stat --printf %g /data/blobstorage/)  # host gid owning the directory
addgroup --gid $GID myhostgroup  # add respective group in container
usermod -G myhostgroup -a plone
exit
  3. commit the container
    docker commit $(docker ps -l --quiet) myplone
  4. and run the new container
     docker run -p 8080:8080 -v $PWD/data/filestorage:/data/filestorage  \
      -v $PWD/data/blobstorage:/data/blobstorage  \
    --entrypoint /docker-entrypoint.sh \
    myplone
4

It makes sense that the directory ownership is relevant. Without knowing what was in place before when it was running correctly, it’s hard to say exactly what an easier solution would have been.