大盘上搭建seafile 12.x的过程简述｜附上升级到13的配置（修改）

tech 2026年04月02日 · 阅读

大盘性能偏弱，1c2G10G+2T
看中seafile的特点：极致的同步性能与极低的开销： Seafile 采用类似 Git 的数据模型，支持块级增量同步。这意味着如果您修改了一个 1GB 视频中的几兆内容，它只会同步修改的切片，这不仅节省带宽，也不会给单核 CPU 带来解压缩/全量传输的负担。

手动创建一个名为 `proxy-net` 的 Docker 网络：

docker network create proxy-net

在 `/data/seafile-compose` 目录下，创建docker-compose.yml文件

seafile:
    image: seafileltd/seafile-mc:12.0-latest
    container_name: seafile
    environment:
      - DB_HOST=db
      - DB_ROOT_PASSWD=${INIT_SEAFILE_MYSQL_ROOT_PASSWORD}
      - TIME_ZONE=${TIME_ZONE}
      - SEAFILE_ADMIN_EMAIL=${INIT_SEAFILE_ADMIN_EMAIL}
      - SEAFILE_ADMIN_PASSWORD=${INIT_SEAFILE_ADMIN_PASSWORD}
      - SEAFILE_SERVER_HOSTNAME=${SEAFILE_SERVER_HOSTNAME}
      - SEAFILE_SERVER_LETSENCRYPT=false
      - JWT_PRIVATE_KEY=${JWT_PRIVATE_KEY} 
    volumes:
      - ${SEAFILE_VOLUME}:/shared
    depends_on:
      - db
      - memcached
    networks:
      - proxy-net
    restart: unless-stopped

networks:
  proxy-net:
    external: true

在/data/caddy/下创建docker-compose.yml

services:
  caddy:
    image: caddy:2
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    environment:
      - SEAFILE_SERVER_HOSTNAME=${SEAFILE_SERVER_HOSTNAME}
      - CADDY_EMAIL=${CADDY_EMAIL}
    volumes:
      - ${SEAFILE_CADDY_VOLUME}/data:/data
      - ${SEAFILE_CADDY_VOLUME}/config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile
    networks:
      - proxy-net
    restart: unless-stopped

networks:
  proxy-net:
    external: true

创建Caddyfile(也可以直接把变量写成常量）

{$SEAFILE_SERVER_HOSTNAME} {
    tls {$CADDY_EMAIL}
    encode gzip
    reverse_proxy seafile:80

# 1. 开启访问日志
    # 限制日志单文件50MB，保留3份
    log {
        output file /data/access.log {
            roll_size 50mb
            roll_keep 3
        }
    }

    # 2. 增加基础安全响应头 (防止网页被恶意嵌套和嗅探)
    header {
        Strict-Transport-Security "max-age=31536000;"
        X-Content-Type-Options nosniff
        X-Frame-Options SAMEORIGIN
    }

    # 3. 反向代理配置增强
    reverse_proxy seafile:80 {
        # 确保后端 Seafile 能获取到访客的真实 IP，而不是 Caddy 的内部 IP
        header_up X-Real-IP {http.request.remote}
        header_up X-Forwarded-For {http.request.remote}
        header_up X-Forwarded-Proto {http.request.scheme}
    }
}

创建一个.env文件

# ==========================================
# 1. 核心存储路径
# ==========================================
# Seafile 核心数据存放路径
SEAFILE_VOLUME=/data/seafile/seafile-data
# 数据库文件存放路径
SEAFILE_MYSQL_VOLUME=/data/seafile/mysql-data
# Caddy 配置文件及申请的 HTTPS 证书存放路径
SEAFILE_CADDY_VOLUME=/data/seafile/caddy-data

# ==========================================
# 2. 基础访问与反向代理配置
# ==========================================
# 您的云盘访问地址。#补充新增-重要-https
SEAFILE_SERVER_PROTOCOL=https
SEAFILE_SERVER_HOSTNAME=您的VPS_IP或域名
# 接收 HTTPS 证书到期提醒的邮箱 (使用域名且开启 Let's Encrypt 才有效)
[email protected]

# ==========================================
# 3. 首次启动初始化配置 (极为重要)
# 注意：以下参数仅在“第一次”拉起容器时生效，后续修改无效！
# ==========================================
# 数据库 root 用户的最高权限密码 (请务必设置复杂密码)
INIT_SEAFILE_MYSQL_ROOT_PASSWORD=设置复杂的_Root_密码
# Seafile 专用的数据库用户密码 (建议与上方密码不同)
INIT_SEAFILE_DB_PASSWORD=设置复杂的_DB_密码

# 您的 Seafile 网盘超级管理员登录账号 (用您的邮箱)
[email protected]
# 您的 Seafile 网盘超级管理员登录密码
INIT_SEAFILE_ADMIN_PASSWORD=设置您的登录密码
#JWT--seafile12要求的JWT私钥；用于容器件验证；随便写一串字符（建议说32位，可随意）
JWT_PRIVATE_KEY=a7b8c434u32unmvdajdc1d2e3f4a5b6
# ==========================================
# 4. 其他环境参数
# ==========================================
# 时区设置为中国上海
TIME_ZONE=Asia/Shanghai
# 由于只有 2G 内存，限制 Memcached 缓存大小以防内存溢出
MEMCACHED_MEMORY_LIMIT=256

摘出其中caddy需要的变量，重新创建一个.env放入/data/caddy；也可以直接复制这个过去。

SEAFILE_SERVER_HOSTNAME=YOUR-DOMAIN.com
CADDY_EMAIL=登录的邮箱
SEAFILE_CADDY_VOLUME=/data/caddy/caddy-data

如果首次创建失败，系统可能初始化不完整，导致你env里设置的邮箱/密码不能登录。Docker 镜像的设定是：只有在“第一次”检测到空数据库时，才会去读取这几个 `INIT_` 变量并创建管理员账号。

救场：这种情况可以新增管理员：

确保Seafile 容器正在运行
在/data/seafile下执行：
```
docker exec -it seafile /opt/seafile/seafile-server-latest/reset-admin.sh
```
输入新邮箱和密码后会显示：Superuser created successfully

重启和重建

docker compose -f /data/seafile/docker-compose.yml restart && docker compose -f /data/caddy/docker-compose.yml restart

如果修改了yml就需要重建

docker compose -f /data/seafile/docker-compose.yml up -d --force-recreate && docker compose -f /data/caddy/docker-compose.yml up -d --force-recreate

搞个alias

echo 'alias restart-cloud="(cd /data/seafile && docker compose down && docker compose up -d) && (cd /data/caddy && docker compose down && docker compose up -d)"' >> ~/.bashrc

执行

source ~/.bashrc

之后只需要

restart-cloud

就可以完成重建docker。

网盘不建议开启CF小黄云，除非很了解使用场景和限制。如网页版上传受限，分发文件涉嫌滥用...本文就不详述了。

seafile详细手册参考：https://manual.seafile.com/12.0/setup/setup_ce_by_docker/

没有输jwt的初始化会生成这样一个账户😳
要进去删掉

继续修

因为使用外部的 Caddy/Nginx/宝塔作为反向代理，需要手动修改 seahub_settings.py 。这是由 Seafile 官方 Docker 的设计决定的：

官方的“默认标准”架构： Seafile 官方提供的默认 docker-compose.yml 其实包含三个容器：数据库 (MariaDB/Memcached)、Seafile 核心应用，以及一个内置的 Nginx 容器。如果完全按官方傻瓜式脚本跑，官方自带的那个 Nginx 会自动配置好这些代理信任头。

自定义架构： Caddy 作为全局 Web 服务器，您通常会砍掉官方那个多余的 Nginx 容器，让 Caddy 直接和 Seafile 核心容器通信。

环境初始化盲区： 当 Seafile 第一次启动时，它的初始化脚本只能根据您 .env 里填写的 SEAFILE_SERVER_HOSTNAME 勉强生成基础配置。它无法预知您外部套了什么反向代理，更不知道外部代理是用什么方式传递 HTTPS 状态的。

因此，所有抛弃官方内置 Nginx、选择自己用外部网关（如 Caddy、Traefik、Nginx Proxy Manager）的用户，在首次启动生成配置后，都需要：手动进入配置目录，告诉核心系统“只需要信任它并生成带有 https 的链接即可”。

' 对于已经初始化过的 Seafile 容器，直接改配置文件才是唯一且官方推荐的解决路径。只要确保这三个参数（SERVICE_URL, FILE_SERVER_ROOT, SECURE_PROXY_SSL_HEADER）设置正确，强制走 HTTPS'

在/data/seafile目录下执行：

docker exec -it seafile vi /shared/seafile/conf/seahub_settings.py

把http修改为https

# ... 这里是文件前面原有的各种配置项 ...

# 强制系统使用 HTTPS 链接
SERVICE_URL = 'https://pan.yourdomain.com'

# 强制文件服务器（上传/下载）使用 HTTPS
FILE_SERVER_ROOT = 'https://pan.yourdomain.com/seafhttp'

# ---- 解决 Mixed Content 问题的关键，加在文件最底下 ----
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

查看目录

docker exec -it seafile ls /shared/seafile/conf/

如果存在ccnet.conf,就需要改：

docker exec -it seafile vi /shared/seafile/conf/ccnet.conf

打开它，将 SERVICE_URL 修改为强制带 https:// 的地址：


[General]
USER_NAME = my-seafile
ID = ...
NAME = my-seafile
# 必须修改这一行，加上 https://
SERVICE_URL = https://pan.yourdomain.com

另外，要确保Caddyfile里有：

header_up X-Forwarded-Proto {http.request.scheme}

最后重启两个容器。网页上传就应该正常了。

⚠️ 建议：修改默认的10MB上传限制（这也是离谱😳）

进入挂载的数据目录中的 Nginx 配置文件：

nano /data/seafile/seafile-data/nginx/conf/seafile.nginx.conf

寻找 client_max_body_size 这个参数。如果找到，把它改成 0（表示无限制）：
```
client_max_body_size 0;
```

保存退出后，重启 Seafile 容器：

docker compose -f /data/seafile/seafile.yml restart seafile

其他

如果仍然上传不成功，日志也没错误。可能是其他用户影响了文件夹权限。
试试：

chmod -R 777 /data/seafile/seafile-data

又折腾了下从seafile12升级到13。先贴个gemini的回答。😑

针对你现在的疑问，我们来复盘一下这些配置到底是不是多余的，以及 Seafile 为什么会把升级搞得这么折腾：

1. 这些环境变量是否多余？

简短回答：不多余，强烈建议全部保留。

DB_HOST=db 与 SEAFILE_MYSQL_DB_HOST=db 并存：
这看起来非常多余，但实际上是 Seafile 架构历史遗留问题的妥协。Seafile 本质上是一个“混合体”：前端 Web 界面（Seahub）是用 Python/Django 写的，而底层处理文件块同步的核心服务（seaf-server）是用 C 语言写的。
目前，Python 前端部分逻辑可能还在向后兼容寻找 DB_HOST，而底层的 C 服务在 13 版本中被强制要求只认 SEAFILE_MYSQL_DB_ 前缀的变量。保留双份是目前最稳妥的做法，能确保上下层组件都不会“迷路”。
.env 里的用户名和数据库名：
绝对不多余。 既然你按照官方升级指南，已经把 seafile.conf 和 seahub_settings.py 里物理的 [database] 和 DATABASES 配置块删除了，那么容器现在完全依赖这些环境变量来知道该往哪里存数据。虽然有些变量如果不写，系统会 fallback 到默认值（比如默认库名就是 ccnet_db），但在复杂的容器化部署中，显式声明永远好于隐式默认。这能让你以后在迁移、备份或排错时一目了然。

2. 这些坑是 Seafile 升级的语法/设计导致的吗？

毫无疑问，是的。这完全是 Seafile 在向云原生架构转型的“阵痛期”带来的代价。

你遇到的这些连接报错、配置找不到的问题，本质上是 Seafile 正在经历一次暴力的底层重构：

从“文件驱动”到“环境变量驱动”的强硬切换：
在 12 及更早的版本中，Seafile 高度依赖挂载出来的物理配置文件（.conf、.py）。启动脚本会去疯狂读取和修改这些文本文件。但在现代容器生态（如 K8s 或纯粹的 Docker Compose）中，大家更希望通过统一的环境变量（.env）来控制一切，避免去改动复杂的文本文件。Seafile 13 强行推进了这一改变，但其初始化脚本对旧配置的兼容处理做得很生硬。
割裂的配置解析逻辑：
正如前面所说，底层 C 语言组件和上层 Python 组件的配置文件甚至都不是同一种格式（一个是 INI 风格，一个是 Python 字典）。官方在推行环境变量时，没能做到让所有组件完美共享同一套变量名，导致了需要加各种前缀的尴尬局面。
官方文档的疏漏：
升级文档告诉你“删掉旧的物理配置”，也提到了“从环境读取”，但并没有明确警告：一旦删除了物理文件，底层 C 服务极度依赖特定的前缀变量，否则会直接 Killed 崩溃。这种信息差是导致你在这个坑里卡住的直接原因。

总结来说：
你现在的配置状态是非常健康且符合现代 Docker 部署规范的。你用环境变量彻底接管了数据库和缓存的调度，摆脱了以前那种既要看 YAML 又要翻 .conf 文件的混乱局面。这个环境现在应该会非常稳定地运行下去。

.env修改后的部分;⚠️注意要从旧的配置文件中找出db_password（如果找不到，看楼下方法重置）；

JWT的字符串要求32位以上（用‘pwgen -s 32 1’生成一个）

# ==========================================
INIT_SEAFILE_MYSQL_ROOT_PASSWORD=自定义
#INIT_SEAFILE_DB_PASSWORD=自定义
INIT_SEAFILE_DB_PASSWORD=1d3a3192-xxxx-xxxx-xxxx-6f88fa1c1fd8 //注意从旧的seafile.conf文件中复制；找下seafile-data/seafile/conf目录
# 您的 Seafile 网盘超级管理员登录email
INIT_SEAFILE_ADMIN_EMAIL=自定义
# 您的 Seafile 网盘超级管理员登录密码
INIT_SEAFILE_ADMIN_PASSWORD=自定义
#补充
SEAFILE_MYSQL_DB_USER=seafile
SEAFILE_MYSQL_DB_CCNET_DB_NAME=ccnet_db
SEAFILE_MYSQL_DB_SEAFILE_DB_NAME=seafile_db
SEAFILE_MYSQL_DB_SEAHUB_DB_NAME=seahub_db
# ==========================================

新的docker-compose.yml（⚠️变量名为了配合env文件，没有命名一致）

services:
  db:
    image: mariadb:10.11
    container_name: seafile-mysql
    environment:
      - MYSQL_ROOT_PASSWORD=${INIT_SEAFILE_MYSQL_ROOT_PASSWORD}
      - MYSQL_LOG_CONSOLE=true
      - MARIADB_AUTO_UPGRADE=1
    volumes:
      - ${SEAFILE_MYSQL_VOLUME}:/var/lib/mysql
    networks:
      - proxy-net
    # --- MariaDB 健康检查 ---
    healthcheck:
      # 明确使用 root 账号和环境变量中的密码进行 ping 测试
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root -p\"$$MYSQL_ROOT_PASSWORD\" || exit 1"]
      interval: 20s
      timeout: 5s
      retries: 5
      start_period: 60s
    restart: unless-stopped

  redis:
    image: ${SEAFILE_REDIS_IMAGE:-redis}
    container_name: seafile-redis
    restart: unless-stopped
    environment:
      - REDIS_PASSWORD=${REDIS_PASSWORD:-}
    networks:
      - proxy-net
    # --- Redis 健康检查 ---
    healthcheck:
      # 兼容无密码和有密码的情况
      test: ["CMD-SHELL", "redis-cli --no-auth-warning -a \"$${REDIS_PASSWORD:-}\" ping | grep PONG"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 10s

  seafile:
    image: seafileltd/seafile-mc:13.0-latest
    container_name: seafile
    environment:
      - DB_HOST=db
      - SEAFILE_MYSQL_DB_HOST=db
      - DB_ROOT_PASSWD=${INIT_SEAFILE_MYSQL_ROOT_PASSWORD}
      - SEAFILE_MYSQL_DB_USER=${SEAFILE_MYSQL_DB_USER:-seafile}
      - SEAFILE_MYSQL_DB_PASSWORD=${INIT_SEAFILE_DB_PASSWORD}
      - TIME_ZONE=${TIME_ZONE}
      - SEAFILE_ADMIN_EMAIL=${INIT_SEAFILE_ADMIN_EMAIL}
      - SEAFILE_ADMIN_PASSWORD=${INIT_SEAFILE_ADMIN_PASSWORD}
      - SEAFILE_SERVER_HOSTNAME=${SEAFILE_SERVER_HOSTNAME}
      - SEAFILE_SERVER_PROTOCOL=https
      - SEAFILE_SERVER_LETSENCRYPT=false
      - JWT_PRIVATE_KEY=${JWT_PRIVATE_KEY}
      - REDIS_PASSWORD=${REDIS_PASSWORD:-}
      - CACHE_PROVIDER=${CACHE_PROVIDER:-redis}
      - REDIS_HOST=${REDIS_HOST:-redis}
      - REDIS_PORT=${REDIS_PORT:-6379}
      - SEAFILE_MYSQL_DB_CCNET_DB_NAME=ccnet_db
      - SEAFILE_MYSQL_DB_SEAFILE_DB_NAME=seafile_db
      - SEAFILE_MYSQL_DB_SEAHUB_DB_NAME=seahub_db
    volumes:
      - ${SEAFILE_VOLUME}:/shared
    # --- 依赖关系更新 ---
    depends_on:
      db:
        condition: service_healthy # 关键修改：等待健康检查通过，不再是简单的 service_started
      redis:
        condition: service_healthy
    networks:
      - proxy-net
    restart: unless-stopped

networks:
  proxy-net:
    external: true

⚠️ 其他升级步骤，必须按官方说明，我就不复制了：

https://manual.seafile.com/13.0/upgrade/upgrade_docker/

SQL密码错误的原因和解决 seafile-mysql容器日志显示：

完成修改后：2026-04-03  4:59:46 18 [Warning] Access denied for user 'root'@'172.18.0.4' (using password: NO)2026-04-03  4:59:48 19 [Warning] Access denied for user 'seafile'@'172.18.0.4' (using password: YES)2026-04-03  4:59:48 20 [Warning] Access denied for user 'root'@'172.18.0.4' (using password: NO)

这个日志非常有价值，它说明了我们之前的修改生效了一部分，但也暴露了目前阻碍系统启动的真正核心问题。

让我们来拆解这三行日志：

root 尝试无密码连接 -> 被拒绝。
seafile 尝试带密码连接 -> 被拒绝 (using password: YES)。
root 再次尝试无密码连接 -> 被拒绝。

这说明 Seafile 的初始化脚本现在的逻辑是：先随便拿 root 探一探（这可能是脚本写死的一个 ping 动作），然后使用了你配置的 seafile 账号和密码去尝试真实连接，但是密码错误，连接失败后，脚本进入了重试循环。

这里的根本原因是：Docker 数据库容器的一个经典“陷阱”。
对于 MySQL/MariaDB 容器，.env 文件中的密码变量（如 SEAFILE_MYSQL_DB_PASSWORD）只有在第一次创建数据库（挂载的 volume 为空）时才会生效。因为你的数据库是从 12 版本继承过来的（volume 已经存在），所以你在 .env 中填写的密码，必须与数据库内部当年初始化时记录的密码完全一致。如果你随便填了一个新密码，它是连不上的。

以下是解决这个密码不匹配问题的步骤：

1. 找回真实的 `seafile` 数据库密码（最稳妥的方法）

如果你之前按照升级手册或我的建议，备份了 12 版本的旧配置文件，这是最简单的办法：

打开你备份的旧的 seafile.conf（或者是 seahub_settings.py）。
在 [database] 块中，找到 password = xxxxxx。
这个 xxxxxx 才是数据库真正认识的密码。
将你的 .env 文件中的 SEAFILE_MYSQL_DB_PASSWORD 修改为这个密码。

2. 手动进入数据库验证密码

为了确认密码到底对不对，我们可以直接跳过 Seafile，在数据库容器内部进行测试。

执行以下命令进入数据库容器的终端：

docker exec -it seafile-mysql bash

然后在容器内部尝试用 seafile 用户登录（回车后会提示你输入密码，输入你认为正确的那个密码）：

mysql -u seafile -p

如果提示 Access denied：说明你的密码彻底不对。你需要继续找旧配置，或者执行第 3 步强制重置密码。
如果成功进入了 MariaDB [(none)]> 提示符：说明密码是对的。输入 exit 退出。如果是这种情况，说明密码包含特殊字符，在 .env 传递时被转义或截断了。你可以尝试在 .env 中给密码加上单引号（例如 SEAFILE_MYSQL_DB_PASSWORD='你的密码'）。

3. 如果密码丢失，强制重置密码（终极方案）

如果你根本找不到旧的密码了，你可以使用 root 账号在数据库内部强制修改 seafile 用户的密码。

同样进入数据库容器：
```
docker exec -it seafile-mysql bash
```
使用 root 登录（输入你 .env 中的 root 密码，即 INIT_SEAFILE_MYSQL_ROOT_PASSWORD 的值）：
```
mysql -u root -p
```
在 MariaDB 命令行中，执行以下 SQL 语句来修改密码（将 你的新密码 替换为你 .env 中写好的那个密码）：
```
ALTER USER 'seafile'@'%' IDENTIFIED BY '你的新密码';
FLUSH PRIVILEGES;
exit;
```
退出容器终端。

完成上述排查和修改后，再次执行 docker compose restart seafile

附注（Ray）: 还是推荐直接装v13吧
https://ytai.de/t/topic/122

caddy selfhosting seafile

大盘上搭建seafile 12.x的过程简述 ｜附上升级到13的配置（修改）

手动创建一个名为 proxy-net 的 Docker 网络：

在 /data/seafile-compose 目录下，创建docker-compose.yml文件