Local backup failure, file exists

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 /var/www/discourse/public/backups/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.

Any tips?

The file structure in the container is different from that outside. The best thing to do is create a new volume that maps the backup directory to wherever you want it to go rather than use a symlink.

1 Like