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!

[stale]

This issue has been automatically marked as stale because it has not had any activity for the last 30 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.