STORAGE_TYPE=local_secure : Scenario improvement?

[BloodyIron]

---

Desired Behavior

I'm not sure what the best/ideal desired behaviour is. But this could be a few different things.

1. /app/www/storage is always linked to a folder within /config
2. When the image detects "STORAGE_TYPE=local_secure" is set to this value, the linking is shifted from /app/www/public/uploads being linked to within /config, to the same/equivalent link point from /app/www/storage instead (but there may be some scenarios this is undesirable?)

Also I think this aspect of Bookstack operations should be documented for this linuxserver image on the relevant documentation pages, as this is baked-in Bookstack functionality, and is preferable from a security operations perspective.

Additionally, I think it's preferable to have one (instead of two) volume mounts for this image to the /config folder as that is deliciously convenient, and falls in-line with other aspects of this image that leverage this convenience. (DELICIOUS work btw all involved)

Current Behavior

The default image seems to be designed for "STORAGE_TYPE=local_secure" not being set (Relevant Bookstack documentation: https://www.bookstackapp.com/docs/admin/security/#initial-security-setup ), in that, out of the box /app/www/public/uploads has a link to /config/www/uploads . Upon initial impression this looks to be a nicely thought out convenience so that when you mount /config to an external storage (EBS? PV/PVC? etc) then uploads will be retained.

However, it seems that when you set "STORAGE_TYPE=local_secure" (which is desirable from a security perspective) that you don't get the same conveniences, in that the /app/www/storage folder is not linked within /config , meaning that I need to make a second volume mapping when using this method. Not exactly world-ending, but somewhat defeating the appreciated conveniences of the /config mappings

Alternatives Considered

Ummm already covered in above discussion?

[BloodyIron]

Since I suspect it is likely to be some time before this is addressed (If it is addressed), in the interim I'm going to use two volume mappings, for anyone curious in my solution, that's what I'm looking to use as a stop-gap. However I think the single volume mapping to /config, even in this scenario, is preferable. Hopefully that can become a thing in time for us to use in Prod version of our Bookstack environment ;)

[ssddanbrown]

Hi @BloodyIron,

This should be already taken into account, and not need a second volume mapping.
Check the www/images folder within your mounted /config volume mapping.

[BloodyIron]

Yeah so I just discovered the mapping /app/www/storage/uploads ... subfolders "files" and "images" are linked to /config/www/files and /config/www/images

So yeah, looks like I got ahead of myself ;)

Maybe mentioning this in the linuxserver.io documentation might be a good idea so users can expect this behaviour?

This sure does look like I'm already having cake and eating it too, whoops! Thanks for the info @ssddanbrown , I literally just discovered it, and then saw your comment. XD go me!

[BloodyIron]

Yeah the more I think about it, an improvement in documentation (for linuxserver.io) would be worthwhile, as it could easily get confused that /config/www/uploads and /config/www/[files|images] serve the same function in different configuration scenarios.

Thoughts?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue is locked due to inactivity