Fallimento backup locale, file esiste

Ho un’istanza di Discourse basata su Docker che viene costruita da un template fornito da DigitalOcean. Quando ho abilitato per la prima volta il backup automatizzato, è stato generato un file di dump in /var/discourse/shared/standalone/backups/default/... come previsto.

Ho deciso di eliminare la directory backups e ho creato un symlink backups che punta a un volume. Da allora, il job di backup sta fallendo (sono anche entrato nel container e ho avviato manualmente il backup, con lo stesso messaggio di errore).
Ecco lo 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'
...

Modifica
Sono entrato nel container e ho eseguito alcune operazioni di debug. Si è scoperto che c’è un symlink che punta /var/www/discourse/public/backups/shared/backups sull’host, che nel mio caso è anch’esso un symlink. C’è un problema di permessi di file che impedisce al processo Ruby di scrivere nella directory backups sull’host.

Qualche consiglio?

1 Mi Piace

La struttura dei file nel contenitore è diversa da quella esterna. La cosa migliore da fare è creare un nuovo volume che mappi la directory di backup nella posizione desiderata, anziché utilizzare un symlink.

2 Mi Piace