Local backup failure, file exists

support
1

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'
...

**Edit
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?

1 Like
2

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.

2 Likes