Tentei isto também:
> root@vps116136-import:/var/www/discourse/config# su discourse -c “bundle exec rake db:drop”
> exec: line 1: “bundle: command not found
Tentei isto também:
> root@vps116136-import:/var/www/discourse/config# su discourse -c “bundle exec rake db:drop”
> exec: line 1: “bundle: command not found
Desculpe, eu deveria ter antecipado essas verificações.
Tente executar o comando drop com esta variável de ambiente:
cd /var/discourse
./launcher enter <seu-nome-do-container>
su discourse
DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop
Este em particular não funcionou porque você não estava no diretório onde o Gemfile do projeto está, no seu caso: /var/www/discourse.
Uma nota rápida: a maneira mais fácil seria ter um backup desde o primeiro início do fórum, assim você simplesmente o restauraria antes de tentar importar novamente, mas assumindo que você não tinha isso, ficamos com esse redefinição suave (soft reset).
Ainda sem sucesso.
root@vps116136-import:/var/www/discourse# su discourse
discourse@vps116136-import:/var/www/discourse$ DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop
PG::InsufficientPrivilege: ERROR: must be owner of database discourse
Couldn’t drop database ‘discourse’
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: must be owner of database discourse (ActiveRecord::StatementInvalid)
…
Tentando agora como root…
Não.
root@vps116136-import:/var/www/discourse# DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop
fatal: detected dubious ownership in repository at ‘/var/www/discourse’
To add an exception for this directory, call:git config --global --add safe.directory /var/www/discourserake aborted!
Esqueça minhas primeiras instruções ![]()
docker cp para copiar seu backup mais recente para fora do contêiner. Os backups ficam em /shared/backups/default../launcher): rm -rf /var/discourse/shared./launcher rebuild \u003ccontainer-name\u003e.Isso deve resolver, mas tenha cuidado para não perder seu backup. Eu estava tentando evitar sugerir isso para que você não excluísse seu backup acidentalmente, mas parece ser o único caminho a seguir.
Vai demorar um pouco. O arquivo tar.gz tem 15GB.
Na verdade, vai levar…

Já foram .5GB desde que comecei.
Concluído.
Feito.
Completo. Pronto para executar o script de importação, mas…
/var/discourse/shared/standalone/import
├── data
├── mysql
└── settings.yml
Eu apaguei isso
à toa, não foi.
Sim.
Eu presumo que você criou um volume para seu contêiner mysql dentro da pasta compartilhada. Se for esse o caso, infelizmente você terá que reiniciar o contêiner e restaurar o banco de dados novamente.
Os anexos você pode simplesmente copiar.
O settings.yml não deve ser tão difícil de configurar novamente.
Não tenho certeza do que significa recriar um contêiner. Na primeira vez, coloquei phpbb_mysql.sql no diretório mysql de acordo com estas instruções. Há mais alguma coisa a fazer além disso?
Os anexos você pode simplesmente copiar.
Sim. Exceto que o tar.gz tem 15GB porque há 45GB de dados no diretório /files do phpBB. Eu administro meu fórum há 22 anos, sabia! Então sim, eu os copiarei de volta. Mas provavelmente, só pegarei isso novamente amanhã.
Sim, essa é a natureza das migrações de comunidade. Um bom conselho seria começar com uma amostra menor e, depois de dominar o processo, você pode executar uma importação completa.
Há esforços em andamento para tornar as ferramentas mais flexíveis e o processo menos redundante, mas este é um assunto muito complexo.
Espero que tudo corra bem na sua execução amanhã.
Concordo! Mas o phpBB não facilita a redução do tamanho da amostra. Estou meio que preso com o que tenho. Ainda assim, era um ambiente de teste e nada é irrecuperável.
Obrigado! Eu postarei aqui depois. A propósito, agora que sou um especialista em docker cp
, seria um grande problema modificar o script ruby para imprimir o post_id do phpBB quando algo assim acontece?
8000 / 24451 ( 32.7%) [677 items/min] W, [2026-01-13T02:50:22.466363 #25640] WARN – : Bad date/time value “0000:00:00 00:00:00”: mon out of range
W, [2026-01-13T02:50:22.466500 #25640] WARN – : Bad date/time value “0000:00:00 00:00:00”: mon out of range
W, [2026-01-13T02:50:22.466600 #25640] WARN – : Bad date/time value “0000:00:00 00:00:00”: mon out of range
Eu ainda estou aqui! Limpando algumas coisas, antes de refazer a importação, e resolvendo alguns problemas. Esperando o Claude me dar um retorno, antes de trabalhar no próximo. Mas, eu voltarei…

OK! Eu resolvi meu último snap sem a ajuda do Claude e iniciei a importação. Mais um obstáculo:
A importação do phpBB3 está começando…
/var/www/discourse/script/import_scripts/phpbb3/support/settings.rb:49:in
initialize': undefined method’ for nil (NoMethodError)
@site_name = import_settings["site_name"]
^^^^^^^^^^^^^
from /var/www/discourse/script/import_scripts/phpbb3/support/settings.rb:11:in `new'
from /var/www/discourse/script/import_scripts/phpbb3/support/settings.rb:11:in `load'
from script/import_scripts/phpbb3.rb:20:in `<module:PhpBB3>'
from script/import_scripts/phpbb3.rb:16:in `<module:ImportScripts>'
from script/import_scripts/phpbb3.rb:15:in `<main>'
NVM, minha culpa. O arquivo settings.yml está estragado. Desculpas, provavelmente só voltarei a isso amanhã.
Você pode brincar com a depuração do pry, você pode adicionar pontos de interrupção no código para abrir o pry quando eles forem executados. Isso permite que você obtenha uma cli interativa para dar uma olhada nos dados. Ou simplesmente adicione um puts row[:post_id] no método process_post, assim quando ele der o aviso você poderá ver o último id.
Sim - isso! Simples para você, nem tanto para mim
Eu usei o Xdebug extensivamente para depuração do lado do servidor do PHP enquanto desenvolvia meus “hacks”, mas estou oficialmente na fase de “cachorro velho e truques novos” da minha vida. Se você puder me fornecer capítulo e versículo, adoraria fazer essa edição - mas não vou fingir que sei mexer com ruby. Pelo menos não ainda…
P.S. O Claude me dará uma audiência em 28 minutos, espero conseguir iniciar a importação depois de superar meu obstáculo atual.
OK, o script de importação está sendo executado com os arquivos .rb revisados. Eu reporto de volta (bocejo) pela manhã.
Uh-oh. Veja o que estou vendo em uma postagem com muitas fotos:
Antes que o MBC possa ser instalado, a bucha da haste de pressão do mestre original deve ser instalada. A bucha fornecida com o kit é muito pequena. Remover o tanque de pressão de ar da unidade PS dá acesso livre para colocar as novas linhas de freio.
~~\[attachment=13\]
51.jpg\[/attachment\]\[attachment=12\]52.jpg\[/attachment\]\[attachment=11\]53.jpg\[/attachment\]\[attachment=10\]54.jpg\[/attachment\]\[attachment=9\]55.jpg\[/attachment\]\[attachment=8\]56.jpg\[/attachment\]\[attachment=7\]57.jpg\[/attachment\]\[attachment=6\]58.jpg\[/attachment\]\[attachment=5\]59.jpg\[/attachment\]\[attachment=4\]60.jpg\[/attachment\]\[attachment=3\]61.jpg\[/attachment\]\[attachment=2\]62.jpg\[/attachment\]\[attachment=1\]63.jpg\[/attachment\]\[attachment=0\]~~64.jpg\[/attachment\]
Veja como essa postagem apareceu no phpBB:
De alguma forma, eu estraguei minha instância do Docker para meu ambiente de teste. Estou no processo de reinstanciá-la.
Em vez de modificar o script de importação, vou tirar um snapshot e pós-processar com um script que pegará um extrato de attach_ids, nomes de arquivos e comentários e tentará adicioná-los como legendas às imagens (com um pouco de ajuda do Claude). Não estou muito otimista, mas avisarei o pessoal como ficou.
Sobre aqueles avisos sobre valores ruins de data/hora, isto do Claude:
O aviso está vindo da gem EXIFR, que lê dados EXIF de arquivos de imagem (seus anexos). Não tem nada a ver com datas de publicação — é sobre metadados nos próprios arquivos de imagem.
O aviso aparece ao processar anexos com metadados de data/hora EXIF inválidos. Isso é cosmético e não afetará sua importação.
O que é como você pensou, @pfaffman. Mas estou feliz em saber agora o gatilho para o aviso.