seafile在linux上可稳定运行，但部署失败主因是setup-seafile-mysql.sh卡住、seahub.sh启动失败及8000端口无法访问；需手动建库授权、降级gunicorn至19.10.0、同步处理firewalld与selinux，并确保seafile与seahub双服务及8000/8020双端口均正常启用。
直接说结论：Seafile 在 Linux 上能稳定跑，但别指望一键装完就万事大吉——setup-seafile-mysql.sh 脚本卡住、seahub.sh 启动失败、8000 端口打不开，这三类问题占了部署失败的 80% 以上。真正耗时的不是安装，而是解决依赖冲突、数据库权限错配和 SELinux 阻断。
MySQL/MariaDB 权限配置必须手写 SQL
Seafile 官方脚本 setup-seafile-mysql.sh 会尝试自动建库建用户，但 CentOS 7+ 默认启用 strict mode，且 MariaDB 10.3+ 对 GRANT 语法更敏感，脚本常在这里静默退出。
- 先手动登录 MySQL：
mysql -u root -p - 执行四条建库语句（注意反引号）：
create database `ccnet-db` character set = 'utf8';、create database `seafile-db` character set = 'utf8';、create database `seahub-db` character set = 'utf8'; - 再建用户并授权（不能用
%，必须指定localhost）：CREATE USER 'seafile'@'localhost' IDENTIFIED BY 'your_strong_password';，然后逐库 GRANT：GRANT ALL PRIVILEGES ON `ccnet-db`.* TO 'seafile'@'localhost';（其余两库同理） - 最后
FLUSH PRIVILEGES;，退出
跳过脚本的自动建库步骤，在脚本提问 “Use existing MySQL server?” 时选 y，后面只填数据库名和用户密码即可。否则脚本会因权限不足反复报错，但错误日志里只显示 Failed to connect to database，不提示具体缺哪条权限。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
seahub.sh 启动失败常见于 Python 环境和 gunicorn 冲突
seahub.sh start 报错退出，十有八九是 Python 模块缺失或版本不兼容。Seafile 6.x–7.x 强依赖 gunicorn==19.10.0，但系统 pip 安装的往往是 21.x+，会导致启动后立即崩溃，日志里只有 ImportError: cannot import name 'parse_qsl' 这类模糊提示。
- 进 Seafile 解压目录下的
seafile-server-*/runtime/，确认 Python 路径：which python，确保是系统自带的/usr/bin/python（不是 Anaconda 或 pyenv 的） - 重装指定版本 gunicorn：
pip install --force-reinstall --no-deps gunicorn==19.10.0 - 检查
seahub/thirdpart/下是否存在gunicorn文件夹，若存在，删掉它（Seafile 自带的第三方包优先级高于系统 pip） - 首次启动前，务必运行：
./seahub.sh setup，它会初始化 Django 数据库表，否则start必然失败
防火墙、SELinux 和端口映射必须同步处理
CentOS 7 默认启用 firewalld + SELinux，两者叠加会让 http://ip:8000 显示连接被拒绝，但 systemctl status seafile 却显示服务“active (running)”——这是最典型的假成功现象。
- 放行两个端口：
firewall-cmd --permanent --add-port=8000/tcp和firewall-cmd --permanent --add-port=8020/tcp（后者是文件上传服务端口），然后firewall-cmd --reload - 检查 SELinux 状态：
getenforce，若为Enforcing，临时设为 permissive：setenforce 0；长期方案是改/etc/selinux/config中SELINUX=disabled，重启生效 - 确认
gunicorn.conf中 bind 地址是0.0.0.0:8000，不是127.0.0.1:8000；同时检查seafile.conf的port=8020是否与实际监听一致 - 用
ss -tlnp | grep ':8000'查看端口是否真被 gunicorn 绑定，而不是被其他进程（如 nginx）占着
真正容易被忽略的是：Seafile 的 Web 服务（seahub）和文件传输服务（seafile）是两个独立进程，分别监听 8000 和 8020。只开一个端口，或只启一个服务，页面能打开但无法上传、同步、预览任何文件——这种半瘫痪状态比完全打不开更难排查。
