No bind volume for uploaded images

[asamarco]

In the docker-compose examples there is no bind volume for the uploaded images in resources (in /var/www/html/Web/uploads/images) or in the "Look and Feel" page (e.g. /var/www/html/Web/img/custom-logo.png).

As a result, if the container is shut down all these customizations are lost.

I would bind mount directly the full Web folder, but maybe there is a better way to ahchieve this.

Thanks,

[colisee]

Hi @asamarco,

Thank you for your suggestion. I will add a section for customization in the RUN.md file.

Later on, I would check for a better way. I can think of 2 options:

1. Let users create sub-folders in the volume to be mapped to /config. Consequently the script entrypoint.sh would perform the appropriate links
2. Create new volume definitions inside Dockerfile

[cptnpopcorn]

Hi @colisee , I just found that using tag docker 3.0.0, together with librebooking v4.0.0, there is a misconfiguration of the /uploads folder. it is not readable by apache itself (while perfectly writeable for PHP).

I temporarily fixed this by docker mounting an additional apache config file into /etc/apache2/conf-enabled, where I give access to that folder:

<Directory "/var/www/html/uploads">
    AllowOverride None
    Require all granted
</Directory>

But it should rather be corrected in the Dockerfile, I guess..

[colisee]

Hi @cptnpopcorn, what is the consequence of apache not being allowed to read the /uploads folder while php has full access to it?

[cptnpopcorn]

HI @colisee , as a consequence, any user-uploaded image appears as an empty rectangle (with the "broken content" symbol in Firefox, at least). I saw that when I tried to upload an image for a resource. Even in the upload dialog, the image shortly is added to the list of images, but without content. Checking the container logs, apache complains about access restrictions for the freshly created image file under /upload

The access rule to enable reads from this folder could possibly be more restrictive, I think there are subfolders for images and another one for attachments. But not sure.

[colisee]

I could reproduce the error you mentioned.

I have a question though.
In file /etc/apache2/apache2.conf, I have the following statements

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

I thought the above statement gave full access to directory /var/www and its children (ex: /var/www/html/uploads). What am I missing?

[cptnpopcorn]

I'm not an expert, but it seems it has to do with the latest apache security policies. "positive" access rules propagate to sub-directories, but only as long as they are under DocumentRoot. And it seems, DocumentRoot is /var/www/html/Web. So, from this perspective, /var/www/html/uploads is outside DocumentRoot and thus not subject to positive access grants of its superior directory.

[ikke-t]

just to confirm I went with mounting custom logo directly to /var/www/html/Web/img/custom-logo.png and it worked. As I'm in kube, I had to base64 the image into config file, and let kube populate the file into container. But eventually the same as bind mount.

[colisee]

@cptnpopcorn

Sorry, I was busy with other activities. I am thus starting all over again

I start a new container "as-is" (no pre-existing volumes) with docker compose up --detach.

I then check that Apache can access and display the existing image /var/www/html/Web/img/librebooking.png

I finally get inside the container, copy the file /var/www/html/Web/img/librebooking.png to /var/www/html/Web/uploads/images/ and check that Apache can access and display the new image Web/uploads/images/librebooking.png

As you can see, it seems to work without making any change...

What did I miss?