多くの調査と試行錯誤の結果、Linux上のDocker Desktopが権限の問題を引き起こしていることがわかりました。
DiscourseアプリケーションはDockerコンテナ内で、discourseという非rootユーザーとして実行されています。しかし、こちらやこちらに書かれているように：
Linux上のDocker Desktopは仮想マシンを実行しており、コンテナはその仮想マシン内で実行されます。この場合、ホストフォルダをコンテナにそのままマウントすることはできません。まず仮想マシンにマウントする必要があります。
そのため、Dockerの専門家ではない私としては、この問題に対処するには2つの方法があると考えています。
(1) Linux上のDocker Desktopを廃止し、代わりにDockerをネイティブで実行する
これは最も持続可能な解決策のように思えます。Discourseコンテナはこのように使用されるように設計されているようです。ただし、イメージ、コンテナ、リソースを管理するためのすべてのコマンドを覚えておく必要があるため、ためらっています。また、フロントエンド開発者としては、管理用のUIがあった方が良いのですが、Dockerについてもっと学ぶための投資として取り組む必要があるのでしょう。
または
(2) コンテナにマウントされたフォルダの所有権を変更する
このアプローチは機能し、Docker DesktopからDiscourseをローカルで正常に実行することに成功しましたが、ターミナルに多くの警告が表示されるため、このソリューションが長期的にどの程度持続可能か確信が持てません。
これにはいくつかの手順が必要です。
ステップ1：リポジトリをクローンする
$ git clone https://github.com/discourse/discourse.git
$ cd discourse
ステップ2：コンテナを初期化する
ホストマシン上のクローンされたdiscourseフォルダ内で、次を実行します。
$ d/boot_dev
何をするか？ こちらを参照してください。
重要：コンテナ作成後に何も実行されないように、--initフラグを省略してください。
ステップ3：フォルダの所有権を変更する
Dockerコンテナ内のdiscourseユーザーのIDは1000です。このガイドでは、ホストマシンのユーザーも同じIDを持っていることを前提としています。ホストマシンのユーザーが異なるIDを持っている場合でも問題が解決しないわけではありませんが、テストできないため、その状況については言及できません。Linuxターミナルでidまたはecho $UIDを実行すると、IDを確認できます。
ホストマシンから、次を実行します。
# Dockerコンテナでシェルを開く
$ d/shell
# すでに/srcにいるはずですが、念のため：
$ cd /src
# /srcの所有権をdiscourseユーザーとグループに変更する
$ chown 1000:1000 .
# /src内のすべてのファイルとフォルダの所有権をdiscourseユーザーとグループに変更する（非再帰的）
$ chown 1000:1000 *
# discourseユーザーとグループにほとんどすべてのサブフォルダの所有権を再帰的に変更する
# 基本的に'database'以外のすべてのフォルダ。これは'postgres'ユーザーとグループに属するためです。
$ chown -R 1000:1000 app bin config d db docs documentation images lib log plugins public script spec test vendor
# 正常に機能したことを確認する。discourseユーザーとグループが表示されるはずです。
$ ls -l
# コンテナを終了する
$ exit
ステップ4：通常どおり続行する
ホストマシンから次を実行して、コンテナのセットアップとDiscourseの起動を続行します。
# gemsをインストールする
$ d/bundle install
# データベースを移行する
$ d/rake db:migrate
$ RAILS_ENV=test d/rake db:migrate
# 管理者ユーザーを作成する
$ d/rake admin:create
# 1つのターミナルで：
d/rails s
# 別のターミナルで
d/ember-cli
注意：
次のような警告に遭遇しました。
fatal: detected dubious ownership in repository at '/src'
これはDocker Desktop on Linuxの仮想化機能によるものです。
これらの警告は無視してください。ホストマシンから、次を実行します。
d/exec git config --global --add safe.directory /src
Linux上のDocker DesktopがVMを実行する理由