I have a docker-based Discourse instance building from a template provided by DigitalOcean. When I enabled automated backup for the first time, a dump file was generated in
/var/discourse/shared/standalone/backups/default/... as expected.
I decided to delete the
backups dir and created a
backups symlink pointing it to a volume. Since then the backup job has been failing (I also entered the container and initiated manual backup, same error message).
Here’s the stack trace:
File exists @ dir_s_mkdir - /var/www/discourse/public/backups /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir' /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir' /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p' /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each' /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p' /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each' /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p' /var/www/discourse/lib/backup_restore/local_backup_store.rb:10:in `base_directory' ...
I entered the container and did some debugging. As it turns out, there’s a symlink pointing
/shared/backups on the host, which is also a symlink in my case. There’s a file permission issue preventing the ruby process from writing to backups dir on the host.