飘在云端

啊!那蓝真天,白真云!

· 备查 · · 1894次浏览

seafile 使用nginx反向代理访问/media路径报403错误

最后更新时间:2020-02-27 09:24
部署环境:seafile 7.1.1 Beta x64 专业版,部署在/root/seafile/,nginx 1.17.6,centos 7.7,运行用户 root,搜索插件运行用户elasticsearch。

nginx使用www用户权限运行,www只是个普通用户权限,安全考虑,我并没有root权限运行nginx。
测试在给了 seafile-server-latest/seahubseahub-data等一堆相关目录0755权限,seafile网页端访问域名abc.com,在abc.com/media 这个url路径,访问以abc.com/media/*开头的资源全部报403错误。

查官方文档手册得知/media是静态资源访问路径,存放css/js/用户头像之类的静态资源,仅需要读权限,按照文档给了所需权限,还是访问不到media下面的资源,唯一区别就是官方文档示例并没有部署在/root 目录 运行seafile。
给seafile这个顶层目录递归了权限755,继续报403错误,重启seafile服务端情况依旧,怀疑是seafile在/root目录运行的原因,单独设定acl,给www用户对root目录下seafile的777权限还是访问不到,百思不得其解。

  • 排除其他原因

selinux一直关闭的
nginx已经具备使用低位端口的权限(小于1024端口)
给nginx 以root权限运行,访问/media路径的资源正常,只是在nginx使用www用户时,始终没有访问 /root/seafile/xxxx/media下面的路径权限,查看nginx配置也没发现什么问题

location /media {

    root /root/seafile/seafile-server-latest/seahub;

}

由于安全风险考虑,不敢给nginx root权限运行,折中办法递归root目录权限0777:

chmod 777 /root -R

进行操作后,还得关闭ssh服务端的严格权限自检, vim /etc/ssh/sshd_config ,把 #StrictModes yes 改成 StrictModes no,然后重启ssh服务端 systemctl restart sshd,不然下次无法ssh登录了。

把root下面的现存目录和文件设定为777,nginx还是使用 www用户和组的身份运行,访问恢复正常。

确定直接原因:nginx的www用户始终访问不到域名/media在文件系统上对应的目录(相关目录和文件的权限都给了),原因未知,再三确认acl权限,/root和/root/seafile目录都给最大权限0777了。
这个坑暂时治标了,没彻底解决,mark一下,后续收拾。

2020-02-27 09:24 更新
原因找到了,是seahub网页端的url入口需要修改,不然访问/media全部会返回403状态码,nginx不需要root权限
解决方案如下,修改网页端或者服务端配置文件
管理员权限账号登陆seafile,进入系统管理

SERVICE_URL值填你反代之后的域名
如 abc.com
继续修改下面的FILE_SERVER_ROOT,值为
http(s)://域名/seafhttp
http://abc.com/seafhttp,如果nginx配置了ssl证书,可以改为https
注意,如果反代的端口号是80,也没配置SSL,只使用http明文方式访问,那么可以不加端口号80
或者反代到443,同时配置了http重定向到https,填的值也是https协议开头的地址,那么也可以不加端口号443
非以上2种情况,就必须加端口号了,否则必定头像报404错误或者/media 报403错误

评论 (0条)