这是一个更新 - 我最终还是让它工作了。一些经验教训可能会帮助到其他人，因此下面有详细的说明。Unix权限的陷阱可能值得添加到OP中。
attachments文件夹上的Unix权限
SMF2导入器运行正常，但有一个关于附件的Unix权限的小陷阱。运行导入脚本时，它以discourse用户身份运行，该用户不一定对attachments卷挂载具有读写权限。
在导入过程中，导入器似乎在该目录中创建了小的临时文件，因此您必须确保正确的用户同时具有读写权限。我通过在主机上递归地将目录chown给discourse用户来做到这一点，但也有其他方法，包括设置非常开放的权限，或使用访问控制列表（ACLs）。
调试失败的上传很困难
如果SMF2导入器因任何原因在上传时失败，它会以相同的方式报告失败，因此很难确定附件/上传失败的原因。
原因可能包括：
- 附件在文件系统中的位置不正确。
- 附件的权限不足（需要
rw）。 - Docker卷挂载未正确设置。
- SMF2数据库报告应该有一个附件，但该附件已在您的attachments文件夹中不存在（在我们的SMF2论坛中，已有约20年的历史，有相当多的“丢失”附件 - 对这些您也无能为力…）
- 上传对象未在Discourse数据库或
/shared/standalone/uploads目录的磁盘上正确保存。 - 未创建上传链接的markdown。
我通过端到端测试附件过程的每一步来调试这个问题，并在smf2.rb代码中添加了大量的额外调试puts语句，以找出上传创建过程中哪些部分不起作用。在我的例子中，有许多小问题，最终一个接一个地被解决了。
不要懒惰，Marcus
最后，我变得懒惰了，没有完全将数据库清零，所以我遇到了一个问题，即一切都成功了 - 但导入器不会覆盖已导入的主题（Topic）或帖子（Post）。因此，引用上传的Markdown，应该看起来像这样：
---
没有被插入到帖子中。
测试是否正常工作
我发现的测试这一切是否端到端工作的办法是运行
Post.where("raw LIKE ?", "%upload://%").count
在Rails控制台中。它会返回实际包含正确上传链接的帖子（Posts）的数量，这个数字在整个导入过程中逐渐增加。