アップロードフォルダの権限は？

インストール
1

まず、半デフォルト設定でDiscourseを実行してみたところ、問題なく動作し、ファイルのアップロードなどもできました。

その後、app.ymlのパスが/var/discourseになっていることに気づき、/var/www/discourseに変更しました。コンテナを停止・破棄し、以前のフォルダを完全に削除してから、再び起動しました。しかし、ファイルがアップロードできなくなっていることに気づきました。

uploadsフォルダにはどのような権限が必要ですか？手動でいくつかの変更はできますが、具体的にどのような権限が必要か、また一般的に問題ないか（特に新規起動時に、ランチャーが適切な権限設定を行うべきではないか？）を知りたいです。

ログにはnginxのエラーが表示されています。

2024/07/12 19:11:23 [crit] 76#76: *160552 stat() “/var/www/discourse/public/uploads/default/original/1X/971c712ff3f1758abc63ac777ad708042cc41ddf.png” failed (13: Permission denied), client: 172.17.0.1, server: _, request: “GET /phorum/uploads/default/original/1X/971c712ff3f1758abc63ac777ad708042cc41ddf.png HTTP/1.0”, host: “myhost.com”, referrer: “https://myhost.com/phorum/admin/site_settings/category/branding”

uploadsの権限は以下のようになっています。

drwxr–r–+ 3 discourse www-data 21 Jul 12 11:47 uploads

2

それが推奨されているものです。

/var/www/discourse パスは、コンテナ内の Discourse へのパスです。/var/discourse は、コンテナ外の Discourse_docker の通常のパスです。

始めたばかりなので、すべてをやり直して、今回は何も名前を変更しないことをお勧めします。

app.yml のパスを更新しなかったため、存在しないものにアクセスしようとしているのだと推測します。

3

このサーバーには他にも多くのプロジェクトがあり、すべて /var/www フォルダにきれいに配置されているため、このように保ちたいです :slight_smile: コンテナ内のことは気にしません。

でも更新しましたよ？マウントで、または他にどこに入れるべきですか？

4

すみません、お手伝いできません。しかし、そこにはNginxがないと確信しています :wink: Dockerコンテナでも状況は同じです。

5

すみません、どのnginxかわかりません。ログはDiscourseのnginxのもので、私のSSL終端nginxはその上にあります。

6

まさにその通りです。リバースプロキシのnginxはそのパスにないのに、なぜDockerコンテナもそうであるべきなのでしょうか。

しかし、コンテナは独自のライフサイクルを持ち、コンテナへのパスは、そのNginxが行うことに影響を与えるべきではありません。他に何か変更しましたか？

7

持っているものを確認しました。

lrwxrwxrwx 1 root root 15 Jul 12 10:10 uploads -> /shared/uploads

そして例として、/var/www/discourse/public/uploads/default/original/1X の画像は以下のようになっています。

-rw-r--r-- 1 discourse www-data 7100 May 19 2022 08335563eac3a393e60a902d4d38cffdfa6d967d

ここまで分かっています。そうでなければ、Docker は私にとって非常に大きな謎です🤣

8

つまり、基本的にワールド書き込み可能ということですか？セキュリティ上問題があるとは考えられていませんか？

9

app.yml の秘密情報を世界に公開するリスクを冒したくはありません。

「いいね！」 1
10

Docker の中ですか？ そんなことはないと思います。それに… どうでもいいことです。なぜなら、それらすべては CDCK によって計画・実行されており、彼らが何をしているか分かっていると信じているからです :smirking_face:

11

確かに、私は何も公開していません :slight_smile:

Docker の内外にかかわらず、権限は同じです。そして、アップロードフォルダはマウントされています。

12

うまくいかなかったので、uploads フォルダのパーミッションを 755 に変更したところ、問題は解決しました。再構築後、アップロード自体は（エンジン側では）問題なかったようですが、nginx がそれらを読み取ることができませんでした。

13

なぜこのようなことをすべて行っているのか、まったく理解できません。世界中に公開されるパスにコンテナを配置するのはあなたの選択ですが、それはあなたの選択です。しかし、それ以外のこと…なぜですか？

Discourse の前にリバースプロキシを配置するのは非常に簡単であり、そうでなければ、セットアップはすべての手間をかけずに標準的なインストールになります。もちろん、遊びたいのであれば、それがあなたの趣味であれば、すぐに誰かが標準的なインストールのみサポートされると言ってくるでしょう。そして最大の課題は、誰もあなたが何をしたのか実際には知らないということです。あるいは、なぜそうしたのかも。

14

「これ」とは何ですか？ 比較的標準的なセットアップです :slight_smile: そして、問題を解決しようとしています。

15

必要であれば、ファイルをアップロードして、その権限を確認し、コピーすることができます。

いくつかアップロードしてから、以下を実行してください。

 find uploads -ls |less
16

あなたは、他のことを始めようとしたときに発生した問題を修正しています。標準的なものが必要な場合でも、リバースプロキシを使用している場合でも同様です。

そのため、標準からかなり離れています :smirking_face: なぜなら、2つの選択肢があるからです。

  • あなたは誰も持っていないバグを抱えている
  • あなたは何かおかしなことをした

おそらくバグでしょう。そして、安全な（多くの意味で）パスを使用して標準的なインストールを行い、同時にリバースプロキシを正しく接続することで、それを確認しました。それでも動作しない場合は、問題は仮想ホストやポートにあると断言できます。しかし、それが機能した場合…「おかしな」選択肢に戻ります。誰もあなたが何をしたのか知りません。

ここに問題が見えますか？

いずれにせよ、リバースプロキシの使用はサポート対象外です…それがここでの方針です。しかし、他のユーザーは助けることができ、しばしば助けてくれます。

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.