starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Config: Allow customization of database backup file permissions #2287

New issue

Open

opened 2026-02-20 01:09:14 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 01:09:14 -05:00

Owner

Originally created by @dannyadair on GitHub (Mar 29, 2025).

Describe what problem this solves and why this would be valuable to many users

At the moment, files written to the "storage" directory are owned by the photoprism user but readable by all.
Database backups - by default also written to the "storage" directory - are not readable by anyone other than the photoprism user.

This can be a pain for syncing/backing up.

The confidentiality of the database/metadata is arguably only slightly higher than that of the actual photos.
While I think that the current permissions are a good default, it would be nice to allow backups to be readable by all.

Describe the solution you'd like

A new setting PHOTOPRISM_BACKUP_WORLDREADABLE or similar which is "false" by default. If "true", read access of backup files should be extended to group and all.

Describe alternatives you've considered

A negated version of the setting like PHOTOPRISM_BACKUP_PRIVATE which is "true" by default. :)
An even more finegrained configuration for the photoprism user's user group, not just "all"
Simply a PHOTOPRISM_BACKUP_FILEMASK to configure file permissions precisely (defaulting to the current 600)

Additional context

I'm using Syncthing to keep all relevant data in another location (basically as a backup). "originals" and "storage" just needed a hidden .stfolder directory owned by the syncthing user, but the database backup files themselves are currently still inaccessible to the syncthing user. Adjusting permissions after running a backup seems like a sledgehammer workaround, it could be a feature and I feel it should be fairly easy to implement.

Thank you for your consideration!

Originally created by @dannyadair on GitHub (Mar 29, 2025). **Describe what problem this solves and why this would be valuable to many users** At the moment, files written to the "storage" directory are owned by the photoprism user but readable by all. Database backups - by default also written to the "storage" directory - are not readable by anyone other than the photoprism user. This can be a pain for syncing/backing up. The confidentiality of the database/metadata is arguably only slightly higher than that of the actual photos. While I think that the current permissions are a good default, it would be nice to allow backups to be readable by all. **Describe the solution you'd like** A new setting `PHOTOPRISM_BACKUP_WORLDREADABLE` or similar which is "false" by default. If "true", read access of backup files should be extended to group and all. **Describe alternatives you've considered** - A negated version of the setting like `PHOTOPRISM_BACKUP_PRIVATE` which is "true" by default. :) - An even more finegrained configuration for the photoprism user's user group, not just "all" - Simply a `PHOTOPRISM_BACKUP_FILEMASK` to configure file permissions precisely (defaulting to the current 600) **Additional context** I'm using Syncthing to keep all relevant data in another location (basically as a backup). "originals" and "storage" just needed a hidden `.stfolder` directory owned by the syncthing user, but the database backup files themselves are currently still inaccessible to the syncthing user. Adjusting permissions after running a backup seems like a sledgehammer workaround, it could be a feature and I feel it should be fairly easy to implement. Thank you for your consideration! ![Image](https://github.com/user-attachments/assets/8bdbcb65-956f-4cd5-ace8-7ea17284ed7f) ![Image](https://github.com/user-attachments/assets/b990f8c8-c598-424a-93af-af629c623f1c)

deekerman added the

idea

security

config

labels

2026-02-20 01:09:14 -05:00

deekerman commented

2026-02-20 01:09:14 -05:00

Author

Owner

@lastzero commented on GitHub (Mar 30, 2025):

This is intentional, as the database dumps contain not only picture and album metadata, but also (strongly hashed, yes) passwords and other personal data that you might not want to share with the world. So while we could add a setting when we have time (right now we really need to work on other issues like improving AI capabilities and batch editing...), I'm not sure to what extent the convenience could lead to disasters... especially on shared servers? 🤔

@lastzero commented on GitHub (Mar 30, 2025): This is intentional, as the database dumps contain not only picture and album metadata, but also (strongly hashed, yes) passwords and other personal data that you might not want to share with the world. So while we could add a setting when we have time (right now we really need to work on other issues like improving AI capabilities and batch editing...), I'm not sure to what extent the convenience could lead to disasters... especially on shared servers? 🤔

deekerman commented

2026-02-20 01:09:15 -05:00

Author

Owner

@dannyadair commented on GitHub (Mar 30, 2025):

Thanks Michael, fair enough (though there is also a false sense of security of your photos and thumbnails, why should they be readable by others)

I shall run a chmod cronjob after the backup job for my purposes.
Very excited about the upcoming features after the spring clean! :)
Esp. the sharing/multiuser features I see in the pipeline.

@dannyadair commented on GitHub (Mar 30, 2025): Thanks Michael, fair enough (though there is also a false sense of security of your photos and thumbnails, why should they be readable by others) I shall run a chmod cronjob after the backup job for my purposes. Very excited about the upcoming features after the spring clean! :) Esp. the sharing/multiuser features I see in the pipeline.

deekerman commented

2026-02-20 01:09:15 -05:00

Author

Owner

@lastzero commented on GitHub (Mar 31, 2025):

Thanks Michael, fair enough (though there is also a false sense of security of your photos and thumbnails, why should they be readable by others)

They won't if you change the umask, e.g. via PHOTOPRISM_UMASK:

https://docs.photoprism.app/getting-started/config-options/#docker-image

I shall run a chmod cronjob after the backup job for my purposes. Very excited about the upcoming features after the spring clean! :) Esp. the sharing/multiuser features I see in the pipeline.

Thanks! We're doing our best to work through the feature requests and open pull requests, most of which were merged/resolved last week and are now ready for testing:

https://docs.photoprism.app/release-notes/#development-preview

@lastzero commented on GitHub (Mar 31, 2025): > Thanks Michael, fair enough (though there is also a false sense of security of your photos and thumbnails, why should they be readable by others) They won't if you [change the umask](https://en.wikipedia.org/wiki/Umask), e.g. via `PHOTOPRISM_UMASK`: https://docs.photoprism.app/getting-started/config-options/#docker-image > I shall run a chmod cronjob after the backup job for my purposes. Very excited about the upcoming features after the spring clean! :) Esp. the sharing/multiuser features I see in the pipeline. Thanks! We're doing our best to work through the feature requests and open pull requests, most of which were merged/resolved last week and are now ready for testing: - https://docs.photoprism.app/release-notes/#development-preview