えー… 
スクリプトは /var/discourse にアクセスする必要すらありません（なぜ必要なのか？）。
問題全体は、いくつかのことから生じています。
- Dockerが何であるか、どのように機能するか、そして何が可能になるかについての大きな誤解
- Docker = docker-compose という考え方を結びつけている（そうではありません！）
ホスト環境にほとんど触れない、完全に分離されたセットアップを持つことができます…
かなりの調査を行った結果、この「セットアップ」スクリプト全体は、技術に詳しくない人にとって可能な限り簡単なインストールを行うために作成されたようです。ユーザーをチェックし、ガイドし、すべてをセットアップします。それは良いことかもしれませんが、想定されたパスからわずかでも外れようとすると、完全に壊れてしまいます。
最も基本的なセットアップでは、ホストディレクトリにアクセスする必要さえありません。すべてが限られた環境内に含まれます（イメージはコンテナを作成するために使用され、必要なすべてのストレージはDockerボリュームを介して処理されます [移行したい場合やファイルにアクセスしたい場合に問題がありますが、ここでは基本的なことを話しています]）。
また、DNSが正しいことを確認し、証明書、リバースプロキシ、SMTPなどをセットアップしようとします。これも、この簡単なセットアップを提供するには完全に問題ありません。
しかし！
問題は、それを破棄することではなく、加えて、プレーンなDockerイメージ（すでに存在し、スクリプトやスクリプトで使用されるテンプレートによって使用されています！discourse_docker/templates/postgres.template.yml at main · discourse/discourse_docker · GitHub & discourse_docker/launcher at main · discourse/discourse_docker · GitHub
- 正しいバージョン管理：イメージをリリースされたDiscourseバージョン（3.4.5など）でタグ付けします。
- 環境変数（データベース/Redisなどの接続を駆動する）と、ホストにマウントできる可能性のあるパス/ボリュームに関する、合理的で簡単なドキュメント。
それだけです…
前述のMinifluxガイドをご覧ください：Miniflux Installation with Docker - イメージ（およびそれを提供するリポジトリ）と設定可能な環境変数に関する詳細が記載されています。
またはMySQL Dockerイメージ：https://hub.docker.com/_/mysql - 同じことです - 設定可能なこと（特に「環境変数」セクションを参照）を説明するガイド。
誰も「MySQLイメージをビルドするためにMySQLランチャーを使用しなければならない」とか、Redisについても同様に言いません。この場合、既存のイメージを使用するだけで、これがDockerを使用する上での手がかりであり、要点です。しかし、Discourseの場合、突然これが「悪い」解決策になり、誰もが「独自のイメージをビルドしなければならない！」と叫びます。なぜですか！？