運用サーバーを扱うときのこの問題の解決策は、すでに述べたように、フォルダーに使用および解決するか、アクセス許可を与えるように、collectstatic を使用することです。ただし、ソリューションがローカル環境にある場合は、ローカルの MEDIA を構成することでソリューションを取得できます settings.py のディレクトリ ローカル サーバーで動作するファイル。
したがって、@Nic Scozzaro が述べたように、ローカル構成ファイルに次の 2 行を追加します。
MEDIA_ROOT = os.path.join (BASE_DIR, 'media')
STATIC_ROOT = os.path.join (BASE_DIR, 'static')
設定後、サービスを再起動して修正を適用してください。
プロジェクトのルートに「MEDIA」ディレクトリを作成します。次に設定します:
MEDIA_ROOT = os.path.join(BASE_DIR,'MEDIA')
ログオンしているユーザーを確認するには:
$ whoami
ubuntu
また、ソリューションに加えて、AWS インスタンスを使用している場合は、ユーザーをグループに追加して、そのフォルダーにアクセスできるようにする必要があります。
Web サービス ユーザーのグループを作成する (varwwwusers)
$ sudo groupadd varwwwusers
www フォルダーを変更し、varwwwusers に属するようにします
$ sudo chgrp -R varwwwusers /var/www/
www-data は django リクエストを作成するサーバーです。それをグループに追加します
$ sudo adduser www-data varwwwusers
フォルダ ポリシーの変更
$ sudo chmod -R 770 /var/www/
varwwwusers のグループに ubuntu を追加
$ usermod -a -G varwwwusers ubuntu
これがお役に立てば幸いです!
私は最終的にこれを自分で解決しました。
開発マシンで実行する場合、実際には現在のユーザーの権限を使用して実行しています。ただし、展開サーバーで実行すると、実際には wsgi まで実行されます 、これは www-data を使用して実行されていることを意味します の特権。
www-data 所有者でも、/var/www を所有するユーザーのグループにも属していません .つまり、www-data other として扱われます 権限が他のユーザーに設定されています。
悪い これに対する解決策は次のとおりです:
sudo chmod -R 777 /var/www/
これにより、全員が /var/www/ のすべてに完全にアクセスできるようになります。 、これは非常に悪い考えです。
別の悪い 解決策は次のとおりです:
sudo chown -R www-data /var/www/
これにより、所有者が www-data に変更されます 、セキュリティの脆弱性を開きます。
良い 解決策は次のとおりです:
sudo groupadd varwwwusers
sudo adduser www-data varwwwusers
sudo chgrp -R varwwwusers /var/www/
sudo chmod -R 760 /var/www/
これにより www-data が追加されます varwwwusers へ /var/www/ のグループとして設定されます。 およびそのすべてのサブフォルダー。 chmod 所有者に読み取り、書き込み、実行権限を付与しますが、たとえば Web サーバーがハッキングされた場合、グループはそこにアップロードされた可能性のあるスクリプトを実行できません。
740 に設定できます より安全にするために、 Django's を使用できなくなります collectstatic 760 に固執する機能 自分のしていることに非常に自信がある場合を除きます。