我目前正在在Ubuntu Linux 16.04上运行的UWSGI / NGINX服务器上进行开发。这几乎是我们在服务器上设置的精确设置（是18.04）。我们在两种环境中都使用Wagtail 2.4和Python 3.6。我已经部署了一个站点，并从media文件夹（从/ media / images和media / original_images文件夹）复制了所有图像。在开发服务器上，我可以很好地编辑每个映像，并且在生产服务器上（无论是与站点还是与管理员），一切都可以正常工作，除了在少数映像上，当我在管理员中并单击在其中之一进行查看/编辑时，这几个会产生错误。它们不在任何特定的集合中，并且具有不同的类型（jpg，png）。生成的错误是：
[Errno 13] Permission denied:
/sites/site_name/media/images/image_name.original.jpg
从在Wagtail管理员中上传图像到对其进行编辑的流程之后，我看到，当首次上传图像时，在/ media / images中创建了三种格式：
然后，当单击图像以对其进行编辑时，xxxxxx.original.xxx版本将放置在/ media / images中。在开发服务器上，我没有单击这几张图像来编辑它们，因此xxxxxx.original.xxx版本未放置在/ media / images中。因此，我这样做了，然后将这些原始版本上载到生产服务器，以解决上述错误。但是，现在，当我单击图像进行编辑时，会遇到相同的错误，除了它正在寻找带有随机生成的字符串作为名称一部分的原件：
[Errno 13] Permission denied:
/sites/site_name/media/images/image_name.original_RANDOM-STRING.jpg
每个原始图像都位于/ media / original_images文件夹中，因此我实际上以为可以从那里拉出并在尝试编辑时在/ media / images中创建xxxxxxx.original.xxx版本。但是为什么不将xxxxxx.original.xxx版本放置在/ media / images文件夹中，却解决了该错误，为什么它随后会查找具有随机生成的字符串的版本，而不是简单地找到xxxxxx.original.xxx版本？
答案 0 :(得分：2)
每当要求对图像进行特殊尺寸的渲染时（通常通过{% image %}模板标签），Wagtail都会检查wagtailimages.Rendition模型（或custom Rendition model，如果您的项目定义了一个），以查看是否存在该源图像和尺寸说明的现有再现记录。如果存在，则提供该现有图像文件的URL；否则，将使用该URL。否则，它将在wagtailimages.Rendition中生成一个新的图像文件和相应的数据库条目。
将文件上传到/media/images/而不创建相应的wagtailimages.Rendition条目将无效，因为Wagtail会看到没有数据库条目，并得出结论，必须创建一个新的图像文件。然后，在保存该文件时，Django分配唯一文件名的逻辑将生效，并为新文件分配一个随机文件名，以避免覆盖您放置在该文件中的文件名。
那么，为此的直接解决方法是，每当您将文件上传到wagtailimages.Rendition时，都将数据库条目添加到/media/images/中。但是，一个更好的主意是修复基础权限错误。我怀疑Django无法创建文件，因为该文件没有对该目录的写权限-有关此问题的解决方法，请参见：
Django [Errno 13] Permission denied: '/var/www/media/animals/user_uploads' 和 https://www.adamerispaha.com/2016/12/14/file-permissions-for-django-media-uploads/