[Bug?] Script in backups container has wrong permissions

  • [x] I’m using stock docker compose setup, unmodified.
  • [ ] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
  • [ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.

  • Tiny Tiny RSS version (including git commit id): 2024-02-06
  • Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions: Debian 12.5

The periodic backup script in the backups container (/etc/periodic/weekly/backup) has permissions 666 instead of 766 (presumably), so the run-parts crontab entry doesn’t actually do anything:

-rw-rw-rw- 1 root root 736 Feb 6 15:12 backup

> / # run-parts /etc/periodic/weekly
> / #

Changing the permissions to 766 and manually executing the run-parts entry works fine:

-rwxrw-rw- 1 root root 736 Feb 6 15:12 backup

> / # run-parts /etc/periodic/weekly
db:5432 - accepting connections
backing up tt-rss database to /backups/ttrss-backup-20240214.sql.gz...
backing up tt-rss local directories to /backups/ttrss-backup-20240214.tar.gz...
tar: removing leading '/' from member names
cleaning up...
done.

As far as I can see, all that needs to be done is the quick permission change!

Thanks, should be fixed after https://gitlab.tt-rss.org/tt-rss/tt-rss/-/merge_requests/24.

FWIW, I checked before updating and my last backup (which I switch to daily by moving the scripts) was from 18th Dec 2023, so this had been broken for ~2 months.

i think any sane person caring about their data is using wal-g (and likely a patroni cluster instead of postgres-in-compose) so it’s no wonder nobody noticed :slight_smile:

p.s. of course its a good thing that op did notice and wn got it fixed