Nginx 提供大图片服务时出现403 Forbidden权限问题

首先咱们先戳破核心问题：你看到的大文件权限是-rw-------（仅文件拥有者可读），小文件却是-rw-r--r--（其他用户也可读），这直接导致Nginx进程（一般是www-data或nginx用户）没法读取大图片，所以出现权限错误。而同一进程上传却出现不同权限，根源在于Django处理大小文件的机制不一样。

为什么大小文件权限会有差异？ #

Django默认有个FILE_UPLOAD_MAX_MEMORY_SIZE配置（默认值是2.5MB）：

• 小于这个阈值的小文件，会直接在内存中处理，写入目标目录时，权限继承Django进程的umask设置（通常是0o022，对应权限644）。
• 大于这个阈值的大文件，Django会先通过Python的tempfile模块创建临时文件（默认权限是0o600，也就是rw-------），再将临时文件移动到你的MEDIA_ROOT目录。移动过程中临时文件的权限会被保留，所以最终大文件的权限就是0o600。

具体解决思路 #

1. 自定义Django存储类，强制统一文件权限

这是最直接且可控的方案，不管大小文件，上传后都强制设置为其他用户可读的权限。

先在你的项目app下新建storage.py文件，写一个自定义存储类：

from django.core.files.storage import FileSystemStorage
import os

class PermissionFixedStorage(FileSystemStorage):
    def _save(self, name, content):
        # 先执行父类的保存逻辑
        file_path = super()._save(name, content)
        # 将文件权限设置为644（所有者读写，其他用户只读）
        os.chmod(file_path, 0o644)
        return file_path

然后在settings.py里指定默认存储类：

DEFAULT_FILE_STORAGE = 'your_app_name.storage.PermissionFixedStorage'

2. 调整Django进程的umask

umask是系统控制文件默认权限的掩码，如果Django进程的umask不是0o022，你可以直接修改它：

• 如果你用Gunicorn启动服务，可以在启动命令前加umask设置：

  umask 0022 && gunicorn your_project.wsgi:application -w 4 -b 127.0.0.1:8000
  

• 或者在Django的wsgi.py开头添加代码：

  import os
  os.umask(0o022)
  

这样临时文件创建时的权限就会变成0o644，移动后也会保留这个权限。

3. 让Nginx用户获得文件读取权限

如果不想修改文件权限，也可以让Nginx用户加入文件所属的用户组：

• 先确认Nginx的运行用户：执行ps aux | grep nginx，找到worker进程的用户（比如www-data）。
• 将该用户加入user1组：sudo usermod -aG user1 www-data。
• 确保上传目录的组权限可执行（让组用户能进入目录）：sudo chmod 750 /var/www/html/medias/images/。
• 最后可以把Django的umask调整为0o002，这样文件权限会变成rw-rw-r--，组用户就能读取了。

4. 检查临时目录权限

Django上传大文件时用的默认临时目录是系统的/tmp，要确保Django进程对这个目录有读写权限。也可以在settings.py里指定自定义临时目录：

FILE_UPLOAD_TEMP_DIR = '/path/to/your/custom/temp/dir'

然后给这个目录设置755权限，确保Django能正常操作。

额外验证步骤 #

• 手动把一个大文件的权限改成644，测试Nginx是否能正常访问，确认权限问题是核心原因。
• 检查/var/www/html/medias/images/目录的权限，确保是755（所有者读写执行，其他用户读执行），这样Nginx才能进入目录读取文件。

内容的提问来源于stack exchange，提问作者penlightment