Tengo una instancia de Discourse basada en Docker que se construye a partir de una plantilla proporcionada por DigitalOcean. Cuando activé la copia de seguridad automatizada por primera vez, se generó un archivo de volcado en /var/discourse/shared/standalone/backups/default/..., como era de esperar.
Decidí eliminar el directorio backups y crear un enlace simbólico backups que apuntara a un volumen. Desde entonces, el trabajo de copia de seguridad ha fallado (también entré en el contenedor e inicié una copia de seguridad manual, obteniendo el mismo mensaje de error).
Aquí está el seguimiento de la pila:
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'
...
Edición
Entré en el contenedor y realicé algunas pruebas de depuración. Resulta que hay un enlace simbólico que apunta /var/www/discourse/public/backups –\u003e /shared/backups en el host, que también es un enlace simbólico en mi caso. Hay un problema de permisos de archivo que impide que el proceso de Ruby escriba en el directorio de copias de seguridad del host.
¿Alguna sugerencia?