Issue with Volume Management for local_secure_restricted Storage Option

[Daschi1]

I am encountering a problem with volume management when using the solidnerd/docker-bookstack image in conjunction with the local_secure_restricted storage option in BookStack. The problem stems from how the Dockerfile declares volumes and the resulting behavior in Docker Compose.

Problem Details:

1. BookStack Storage Option Impact:

   • When using the local_secure_restricted storage option, files are stored in storage/uploads/images and storage/uploads/files instead of public/uploads and storage/uploads.
   • This change is aligned with secure file storage but introduces conflicts with the Dockerfile’s declared volumes.

2. Dockerfile Volume Declarations:

   • The Dockerfile declares the following volumes:

     VOLUME ["/var/www/bookstack/public/uploads", "/var/www/bookstack/storage/uploads"]

   • Docker automatically creates anonymous volumes for these paths if they are not explicitly overridden in docker-compose.yml.

3. User Volume Mapping Conflicts:

   • In my setup, I use a single external volume, bookstack-storage, to store all persistent data.
   • However, due to the Dockerfile’s VOLUME declarations, I must explicitly map the corresponding subdirectories (e.g., public/uploads and storage/uploads) to avoid anonymous volumes.
   • This requires hardcoding the host path for the external volume, which reduces portability and scalability.

   Example workaround in docker-compose.yml:

   volumes:
     - bookstack-storage:/var/www/bookstack/storage
     # Explicitly map subdirectories to prevent anonymous volumes
     - /var/lib/docker/volumes/bookstack-storage/_data/uploads:/var/www/bookstack/storage/uploads
     - /var/lib/docker/volumes/bookstack-storage/_data/public/uploads:/var/www/bookstack/public/uploads

   • This approach is not ideal as it:
     • Requires hardcoding the host path (e.g., /var/lib/docker/volumes/bookstack-storage/_data).
     • Reduces portability and adds complexity to the setup.

Request for Discussion and Potential Fix:

I would like to discuss potential ways to address this issue. A few ideas include:

1. Revisiting VOLUME Declarations:

   • Consider removing the VOLUME declarations for /public/uploads and /storage/uploads from the Dockerfile. This would allow users to manage all volumes explicitly in their docker-compose.yml files without interference.

2. Environment Variable-Based Volume Control:

   • Introduce an environment variable to enable or disable the automatic creation of volumes for /public/uploads and /storage/uploads.

3. Improved Documentation:

   • Update documentation to explain the behavior of the VOLUME directive and provide a recommended approach for users wanting to use a single volume (e.g., with the local_secure_restricted option).

Conclusion:

This issue complicates the use of local_secure_restricted storage in Dockerized setups and creates challenges for those who want to use a single volume for storage. Addressing this would improve usability and scalability for users of this project.

Looking forward to hearing your thoughts and discussing possible solutions!