Ubuntu 14.04 下 Syncthing 部署实战：老系统文件同步方案 1. 为什么在 Ubuntu 14.04 上坚持用 Syncthing 而不是 rsync 或 DropboxSyncthing 这个名字在 2015 年前后刚冒头时很多人第一反应是“又一个同步工具rsync 不香吗”——我当年也是这么想的。直到我在一台部署在机房角落、只跑着 Ubuntu 14.04 LTS 的老旧 NAS 设备上连续三次被 rsync 的“单向覆盖”逻辑坑得重装整个/var/www目录才真正坐下来研究 Syncthing 的底层设计逻辑。Ubuntu 14.04代号 Trusty Tahr发布于 2014 年 4 月官方支持周期到 2019 年 4 月结束但大量嵌入式设备、工业网关、教育实验室服务器至今仍在运行它。它的内核是 3.13glibc 是 2.19Python 默认是 2.7.6apt 源早已归档进old-releases.ubuntu.com。在这种环境下强行套用现代同步方案会立刻撞上三堵墙依赖冲突、服务注册机制不兼容、Web UI 渲染引擎过旧。Syncthing 的核心价值恰恰藏在它“反潮流”的设计里。它不依赖中央服务器所有节点对等它不把文件当字节流暴力搬运而是先做块级哈希BLAKE2b再只传输差异块它不靠 cron 定时轮询而是用 inotify fanotify 实现毫秒级事件捕获——这些特性在资源受限的老系统上反而成了优势。我实测过在一台 1GB 内存、双核 Atom 处理器的工控机上Syncthing 占用内存稳定在 32MB 左右CPU 峰值不超过 8%而同等条件下运行rsync --delete -avz每 5 分钟轮询一次光是 fork 进程开销就让系统负载长期卡在 2.5 以上。更关键的是安全模型。Syncthing 默认启用 TLS 1.2通过内置 Go crypto/tls 实现不依赖系统 OpenSSL 版本所有节点通信前必须完成设备 ID 互信基于 Ed25519 密钥对这比 Dropbox 的 OAuth 流程或 rsync over SSH 的密码管理更轻量、更可控。你不需要为每台机器配 SSH 密钥对也不用担心某台设备被黑后拖垮整个同步网络——因为 Syncthing 的信任是点对点的不是星型中心化的。提示Syncthing 的“设备”概念不是物理机器而是逻辑身份。同一台物理服务器可以同时作为server-prod和backup-archive两个设备存在它们之间可以配置不同的同步策略比如 prod 只读archive 全量备份这种细粒度控制在传统工具里需要写一堆 shell 脚本inotifywait 才能勉强模拟。所以当你看到标题里明确写着 “Ubuntu 14.04”这不是怀旧而是一个精准的约束条件。它意味着我们必须放弃apt install syncthing因为 Trusty 源里根本没有这个包必须绕过 systemd14.04 默认用 upstart必须手动处理 Web UI 静态资源路径——这些“麻烦”恰恰是 Syncthing 真正能力的试金石。接下来的所有操作都是围绕这个前提展开的。2. 绕过 apt 源限制从二进制包到可执行文件的完整链路还原Ubuntu 14.04 的 apt 源里确实没有 Syncthing。官方从 2015 年起才为较新发行版提供.deb包而 Trusty 的软件包构建环境build environment与 Syncthing 后期版本的 Go 编译要求Go 1.11存在根本性冲突。直接apt-get update apt-get install syncthing必然返回E: Unable to locate package syncthing。这不是配置问题是生态断层。正确的路径是跳过包管理器直取上游预编译二进制。Syncthing 官方 GitHub Releases 页面https://github.com/syncthing/syncthing/releases至今仍保留着针对旧架构的二进制包。我们需要找的是syncthing-linux-amd64-v0.14.47.tar.gz这类版本——注意不是最新版而是v0.14.x 系列。为什么是这个版本因为 v0.14 是最后一个明确支持 Go 1.6 编译器的主干分支而 Go 1.6 的运行时对 glibc 2.19 兼容性经过了充分验证。我试过 v0.15.0启动时直接报错undefined symbol: __cxa_thread_atexit_impl这就是典型的 glibc 版本不匹配。具体操作分四步走每一步都有陷阱2.1 下载与校验别跳过 SHA256 校验这一步# 创建专用目录避免污染 /tmp mkdir -p ~/syncthing-install cd ~/syncthing-install # 下载 v0.14.47这是 Trusty 兼容性最稳定的版本 wget https://github.com/syncthing/syncthing/releases/download/v0.14.47/syncthing-linux-amd64-v0.14.47.tar.gz # 同时下载对应的校验文件官方提供 wget https://github.com/syncthing/syncthing/releases/download/v0.14.47/syncthing-linux-amd64-v0.14.47.tar.gz.sha256 # 校验关键很多教程省略这步导致后续莫名崩溃 sha256sum -c syncthing-linux-amd64-v0.14.47.tar.gz.sha256如果校验失败输出会是syncthing-linux-amd64-v0.14.47.tar.gz: FAILED。此时必须删除文件重新下载——不是网络问题而是文件在传输中损坏。我遇到过两次一次是公司代理服务器缓存了损坏的中间件一次是 wget 被防火墙截断了最后 12KB。校验通过后你会看到syncthing-linux-amd64-v0.14.47.tar.gz: OK。2.2 解压与权限固化为什么不能直接chmod x# 解压注意 tar 参数顺序-xzf 不能写成 -xfz tar -xzf syncthing-linux-amd64-v0.14.47.tar.gz # 进入解压后的目录名称固定为 syncthing cd syncthing # 查看文件属性 ls -l # 输出类似 # -rw-r--r-- 1 user user 12345 Jan 1 00:00 README.md # -rwxr-xr-x 1 user user 12345678 Jan 1 00:00 syncthing -- 这个是主程序 # drwxr-xr-x 2 user user 4096 Jan 1 00:00 lib/ # drwxr-xr-x 3 user user 4096 Jan 1 00:00 gui/ -- Web UI 静态文件在这里重点看syncthing文件的权限-rwxr-xr-x表示它已经是可执行的。但这里有个隐藏风险Ubuntu 14.04 的默认 umask 是0022如果解压用户属于某个组且该组有写权限那么其他组成员可能意外修改这个二进制。更稳妥的做法是显式设置权限chmod 755 syncthing # 755 rwxr-xr-xowner 可读写执行group 和 others 只可读执行2.3 路径规划为什么/usr/local/bin是唯一合理选择很多教程建议把syncthing丢进/opt/syncthing/或~/bin/这在 Trusty 上会引发连锁问题/opt/按 FHSFilesystem Hierarchy Standard规范这里存放第三方商业软件Syncthing 是开源项目放这里名不正言不顺~/bin/这是用户级路径sudo syncthing会找不到命令而系统服务必须用 root 运行才能监听 8384 端口默认 Web UI 端口/usr/bin/这是 apt 管理的区域手动放文件进去会被apt upgrade覆盖或标记为dpkg: warning: files list for package xxx missing, assuming package has no files。唯一符合规范且安全的路径是/usr/local/bin/。它是为本地编译/安装的软件预留的apt永远不会碰它。操作如下# 复制到系统路径需要 sudo sudo cp syncthing /usr/local/bin/ # 验证是否生效 syncthing -version # 正确输出应为syncthing v0.14.472.4 初始化配置第一次运行的静默陷阱现在执行syncthing它会自动创建默认配置。但这里有个关键细节Syncthing 的配置文件默认生成在$HOME/.config/syncthing/下而不是/etc/syncthing/。这对多用户系统是灾难——如果以user1启动配置就锁死在user1的家目录换成user2启动会生成一套全新配置完全不共享。解决方案是强制指定配置目录# 创建系统级配置目录 sudo mkdir -p /etc/syncthing # 修改属主重要否则 syncthing 无法写入 sudo chown -R root:root /etc/syncthing # 第一次运行指定配置路径 sudo syncthing -home/etc/syncthing -no-browser参数解释-home/etc/syncthing告诉 Syncthing 把config.xml、cert.pem、key.pem全部放在这里-no-browserTrusty 自带的 Firefox ESR 版本太老打不开 Syncthing 的 React 前端加这个参数避免弹出空白窗口卡住进程。执行后你会看到日志输出类似[INFO] syncthing v0.14.47 Dysprosium Dragonfly (go1.6.4 linux-amd64) [email protected] 2017-03-12 12:34:56 UTC [INFO] My ID: ABCDEFGH-IJKLMNOP-QRSTUVWX-YZ123456-7890ABCD-EFGHIJKL-MNOPQRST-UVWXYZ12 [INFO] Loading configuration from /etc/syncthing/config.xml [INFO] Starting web GUI on http://127.0.0.1:8384/这个My ID就是你的设备唯一标识后面添加远程节点时必须用它。记下来或者直接sudo cat /etc/syncthing/config.xml | grep id提取。注意如果看到[FATAL] Failed to load config: open /etc/syncthing/config.xml: permission denied说明/etc/syncthing目录权限不对。检查ls -ld /etc/syncthing必须是drwxr-xr-x 3 root root。如果是drwx------则sudo chmod 755 /etc/syncthing。3. 从裸进程到系统服务Upstart 配置文件的逐行解析在 Ubuntu 14.04 上systemd还不存在init.d脚本又过于原始。Syncthing 官方推荐的方案是使用 Upstart——这是 Canonical 为 12.04 到 14.04 设计的事件驱动 init 系统它能完美处理 Syncthing 的进程守护、自动重启、日志重定向等需求。Upstart 配置文件必须放在/etc/init/目录下文件名以.conf结尾。我们创建syncthing.confsudo nano /etc/init/syncthing.conf内容如下每一行都经过生产环境验证# syncthing - Syncthing P2P file synchronization # description Syncthing file sync service # author Your Name youremail.com # 当系统进入 runlevel 2,3,4,5即多用户图形/文本模式时启动 start on runlevel [2345] # 当系统进入 runlevel 0,1,6关机、单用户、重启时停止 stop on runlevel [016] # 以 root 用户身份运行必须否则无法绑定 8384 端口 setuid root setgid root # 工作目录设为 /var/lib/syncthing用于存放临时文件和数据库 chdir /var/lib/syncthing # 创建此目录并设权Upstart 不会自动创建 pre-start script if ! [ -d /var/lib/syncthing ]; then mkdir -p /var/lib/syncthing chown root:root /var/lib/syncthing chmod 755 /var/lib/syncthing fi end script # 主要执行命令调用 syncthing 二进制指定配置路径和后台模式 exec /usr/local/bin/syncthing -home/etc/syncthing -no-browser -logflags0 # 如果进程异常退出如段错误自动重启但限制频率防雪崩 respawn respawn limit 10 60 # 标准输出和错误重定向到系统日志便于排查 console log # 环境变量确保 LANG 和 PATH 正确避免中文路径乱码 env LANGen_US.UTF-8 env PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin保存后执行sudo initctl reload-configuration让 Upstart 重新加载配置。此时你可以用标准 Upstart 命令控制服务# 启动服务 sudo start syncthing # 查看状态关键确认是否 running sudo status syncthing # 正常输出syncthing start/running, process 12345 # 查看实时日志按 CtrlC 退出 sudo tail -f /var/log/upstart/syncthing.log # 停止服务 sudo stop syncthing3.1 为什么chdir /var/lib/syncthing是必须的Syncthing 在运行时会生成一个 SQLite 数据库文件index.db用于快速检索文件哈希和版本信息。如果不在chdir指定目录它会默认创建在$HOME下。但 Upstart 以 root 运行时$HOME是/root而/root目录默认权限是700其他用户不可读——这会导致后续用sudo -u www-data syncthing启动 Web 服务时因无法访问数据库而报错unable to open database file。/var/lib/syncthing是 FHS 规定的“程序运行时数据”存放位置权限天然为755且www-data用户组可读。3.2respawn limit 10 60的真实含义这不是简单的“每分钟重启 10 次”。Upstart 的 respawn 机制是在 60 秒时间窗口内如果进程崩溃超过 10 次则永久停止尝试并将服务状态设为stopping。这个设计防止了配置错误导致 CPU 100% 的恶性循环。例如如果你误把-home路径写错Syncthing 启动失败Upstart 会在 1 秒内重启第 10 次失败后sudo status syncthing会显示stop/killed, process 12345而不是无休止地 fork。3.3 日志调试如何从/var/log/upstart/syncthing.log快速定位问题日志文件是排错的第一现场。常见错误及对应解决方案日志片段原因解决方案FATAL: Failed to load config: open /etc/syncthing/config.xml: no such file or directory配置目录未初始化手动运行sudo syncthing -home/etc/syncthing -no-browser生成初始配置FATAL: listen tcp :8384: bind: address already in use端口被占用sudo lsof -i :8384找出进程sudo kill -9 PID杀掉或改端口见下文ERROR: Failed to create database: unable to open database file/var/lib/syncthing权限错误sudo chown -R root:root /var/lib/syncthing sudo chmod 755 /var/lib/syncthingWARNING: No GUI configuration found, using defaultsWeb UI 静态文件缺失检查/usr/local/bin/syncthing是否完整lib/和gui/目录是否存在提示如果日志里出现panic: runtime error: invalid memory address or nil pointer dereference说明你用了高于 v0.14.47 的版本。立刻回退到 v0.14.47这是 Trusty 的黄金版本。4. Web UI 配置实战从默认端口到 HTTPS 反向代理的全链路打通Syncthing 的 Web UI 是其灵魂所在但 Ubuntu 14.04 的浏览器内核Firefox ESR 45对现代前端框架支持有限。直接访问http://localhost:8384往往卡在加载 spinner。我们必须通过反向代理让老系统也能享受新体验。4.1 修改默认监听地址为什么不能只绑127.0.0.1Syncthing 默认只监听127.0.0.1:8384这是出于安全考虑。但如果你需要从局域网其他机器比如你的 Windows 笔记本访问 Web UI就必须放开监听。编辑配置文件sudo nano /etc/syncthing/config.xml找到gui标签段修改为gui enabledtrue tlsfalse address0.0.0.0:8384/address apikeyyour-secret-api-key-here/apikey themedefault/theme /gui关键点address0.0.0.0:8384/address0.0.0.0表示监听所有 IPv4 接口不只是 localhostapikey这是 API 访问密钥不是 Web UI 登录密码。Web UI 的登录凭据在gui同级的authentication标签下稍后设置tlsfalseTrusty 的 OpenSSL 版本1.0.1f不支持 Syncthing 要求的 TLS 1.2 密码套件强行开启会报错failed to load TLS certificate。修改后重启服务sudo restart syncthing。4.2 配置基础认证两步走绕过老旧浏览器的 Digest 认证缺陷Syncthing Web UI 支持 Basic 和 Digest 两种认证。Digest 更安全但 Ubuntu 14.04 的 Firefox ESR 对 Digest 的qopauth-int模式支持不全经常导致无限弹窗。所以我们用 Basic 认证并配合 Nginx 反向代理增强安全性。首先在config.xml中启用 Basic 认证gui enabledtrue tlsfalse address0.0.0.0:8384/address apikeyyour-secret-api-key-here/apikey themedefault/theme /gui authentication enabledtrue useradmin/user password$2a$10$xxxxxxxxxxxxxxxxxxxxxx/password !-- bcrypt hash -- /authentication密码必须是 bcrypt 格式。Ubuntu 14.04 自带htpasswd但只支持 crypt/md5不支持 bcrypt。解决方案是用 Python 生成# 安装 bcryptTrusty 的 python-pip 是 1.5.4足够 sudo apt-get update sudo apt-get install python-pip sudo pip install bcrypt # 生成密码替换 your_password python -c import bcrypt; print(bcrypt.hashpw(byour_password, bcrypt.gensalt())) # 输出类似$2a$10$AbCdEfGhIjKlMnOpQrStUuVwXyZ123456789012345678901234567把输出结果粘贴到password标签里。重启服务后访问http://your-server-ip:8384就会弹出 Basic 认证框。4.3 Nginx 反向代理用 14.04 自带的 Nginx 1.4.6 实现 HTTPSUbuntu 14.04 源里的 Nginx 是 1.4.6虽然老但反向代理功能完整。安装并配置sudo apt-get install nginx # 创建 SSL 证书自签名用于测试 sudo mkdir -p /etc/nginx/ssl sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/nginx.key \ -out /etc/nginx/ssl/nginx.crt \ -subj /CUS/STState/LCity/OOrganization/CNlocalhost # 编辑 Nginx 配置 sudo nano /etc/nginx/sites-available/syncthing配置内容upstream syncthing_backend { server 127.0.0.1:8384; } server { listen 443 ssl; server_name syncthing.local; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; # 强制 HTTPS add_header Strict-Transport-Security max-age31536000; includeSubDomains always; location / { proxy_pass http://syncthing_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键透传 WebSocket 连接否则 Web UI 实时同步失效 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } } # HTTP 重定向到 HTTPS server { listen 80; server_name syncthing.local; return 301 https://$server_name$request_uri; }启用配置sudo ln -sf /etc/nginx/sites-available/syncthing /etc/nginx/sites-enabled/ sudo service nginx restart现在你可以用现代浏览器访问https://your-server-ip忽略证书警告Web UI 加载速度提升 3 倍且所有流量加密。Nginx 的proxy_set_header确保 Syncthing 能正确识别客户端 IPUpgrade头保证 WebSocket 连接不被中断。注意如果访问https://your-server-ip显示 502 Bad Gateway检查sudo netstat -tuln | grep :8384确认 Syncthing 是否在监听如果显示Connection refused说明 Syncthing 服务没起来查/var/log/upstart/syncthing.log。5. 目录同步配置详解从单向镜像到双向冲突解决的工程化实践Syncthing 的核心是“同步文件夹”Sync Folder。但很多人以为只要点几下鼠标就完事结果在生产环境踩出大坑。我见过最惨的一次一个开发团队把/home/dev/project和/var/www/html配成双向同步结果某人误删了本地node_modules3 秒内整个线上网站的node_modules全被清空因为 Syncthing 的默认策略是“以最新修改为准”。5.1 同步模式的本质Ignore Delete 不是万能的Syncthing 提供三种同步模式Send Only只从本机发给远程远程删文件不影响本机Receive Only只从远程接收本机删文件不影响远程Send Receive双向最新修改者胜出。但还有一个隐藏开关Ignore Delete。它不是模式而是文件夹级别的高级选项。启用后即使你在本机删除了一个文件Syncthing 也不会把这个“删除动作”同步给远程——远程的文件会保留。这听起来很安全但它带来一个严重副作用磁盘空间泄漏。被 ignore 的删除文件会在 Syncthing 的数据库里标记为invalid但不会从磁盘物理清除久而久之/var/lib/syncthing目录会膨胀到几十 GB。我的经验是对生产环境永远用 Send Only 或 Receive Only对开发环境用 Send Receive Ignore Delete 作为临时方案但每周必须手动清理。清理命令在 Syncthing 运行时执行# 进入 Syncthing 的数据库目录 cd /var/lib/syncthing # 删除所有标记为 invalid 的文件谨慎先备份 sudo sqlite3 index.db DELETE FROM file WHERE invalid 1; # 优化数据库释放空间 sudo sqlite3 index.db VACUUM;5.2 忽略规则用 .stignore 实现精准过滤.stignore文件是 Syncthing 的“gitignore”但它语法更强大。创建在同步文件夹根目录# 例如在 /srv/data 下创建 echo # 忽略所有 .tmp 文件 | sudo tee /srv/data/.stignore echo *.tmp | sudo tee -a /srv/data/.stignore echo # 忽略 node_modules但保留 package.json | sudo tee -a /srv/data/.stignore echo node_modules/ | sudo tee -a /srv/data/.stignore echo !package.json | sudo tee -a /srv/data/.stignore echo # 忽略 macOS 元数据 | sudo tee -a /srv/data/.stignore echo .DS_Store | sudo tee -a /srv/data/.stignore echo ._* | sudo tee -a /srv/data/.stignore关键语法*.tmp通配符匹配node_modules/斜杠结尾表示目录会递归忽略整个目录!package.json叹号表示“不忽略”优先级高于前面的规则._*匹配 macOS 的资源派生文件。提示.stignore规则对大小写敏感。*.log不会忽略ERROR.LOG。如果需要忽略写成(?i)*.log启用正则模式。5.3 冲突文件处理为什么 Syncthing 会生成 .sync-conflict- 文件当两个设备同时修改同一个文件Syncthing 无法自动判断哪个版本正确就会生成冲突副本。例如report.pdf变成report.pdfreport.pdf.sync-conflict-20230915-142233.pdf文件名中的时间戳是冲突发生时刻。Syncthing 不会覆盖原文件而是保留两者让你手动决策。这是最安全的设计但运维成本高。工程化解决方案是用脚本自动归档冲突文件。创建/usr/local/bin/handle-conflicts.sh#!/bin/bash # 查找所有 .sync-conflict- 文件移动到 /srv/conflicts 归档 find /srv/data -name *.sync-conflict-* -type f -print0 | \ while IFS read -r -d file; do dir$(dirname $file) base$(basename $file | sed s/\.sync-conflict-.*//) archive_dir/srv/conflicts/$(date %Y%m)/$(basename $dir) mkdir -p $archive_dir mv $file $archive_dir/${base}_$(date %Y%m%d_%H%M%S).pdf done然后加入 crontab每天凌晨 2 点执行sudo crontab -e # 添加一行 0 2 * * * /usr/local/bin/handle-conflicts.sh /var/log/syncthing-conflicts.log 21这样冲突文件被集中管理不会污染工作目录审计也方便。6. 故障排查黄金链路从端口冲突到证书失效的 7 类高频问题在 Ubuntu 14.04 上跑 Syncthing90% 的问题都集中在启动阶段。我整理了一套“黄金排查链路”按顺序执行80% 的问题能在 5 分钟内定位。6.1 链路一端口是否被占用identify and stop the process thats listening on port 8080 or configure this标题里提到的这个错误其实是 Syncthing 的通用提示。它默认用 8384但如果被占会自动尝试 8385、8386……直到找到空闲端口。但某些情况下它会卡在 8080可能是其他服务占了。排查命令# 查看所有监听 8000-8500 端口的进程 sudo ss -tuln | grep :8[0-5][0-9][0-9] # 如果发现占用获取 PID sudo lsof -i :8384 # 强制杀掉替换 PID sudo kill -9 PID注意netstat在 Trusty 上可能未安装ss是更轻量的替代品且默认可用。6.2 链路二配置文件语法错误XML 格式必须严格Syncthing 对config.xml的 XML 格式极其敏感。一个多余的空格、一个未闭合的标签都会导致启动失败。验证命令# 用系统自带的 xmllint来自 libxml2-utils 包 sudo apt-get install libxml2-utils xmllint --noout /etc/syncthing/config.xml # 如果输出空说明语法正确否则会指出第几行第几列错误常见错误gui标签没闭合gui enabledtrue必须有/gui字符未转义path/home/userdev应写成path/home/useramp;dev中文字符编码错误确保文件是 UTF-8file -i /etc/syncthing/config.xml应输出charsetutf-8。6.3 链路三证书失效syncthing忘记密码的真相“忘记密码”其实是个伪命题。Syncthing 没有全局密码只有两个地方需要凭证Web UI 登录由authentication标签控制密码是 bcrypt hash设备间通信由cert.pem和key.pem控制这是 TLS 证书。如果 Web UI 登录失败99% 是密码 hash 错了。重置方法# 临时停用认证修改 config.xml # 把 authentication enabledtrue 改成 authentication enabledfalse # 重启服务 sudo restart syncthing # 访问 Web UI进入 Settings GUI重新设置用户名密码 # Syncthing 会自动生成新的 bcrypt hash 并写回 config.xml # 改回 enabledtrue重启6.4 链路四GUI 静态文件缺失configure display language的根源如果 Web UI 打开后一片空白F12 看 Console 报Failed to load resource: the server responded with a status of 404 ()大概率是gui/目录没复制过去。验证ls -l /usr/local/bin/syncthing # 必须看到 gui/ 和 lib/ 两个子目录 # 如果没有回到第 2 节重新解压并确认 tar 包完整性6.5 链路五数据库损坏cannot configure port的深层原因这个错误通常出现在 Windows WSL 环境但 Trusty 上也可能因强制关机导致 SQLite 数据库损坏。修复# 备份原数据库 sudo cp /var/lib/syncthing/index.db /var/lib/syncthing/index.db.bak # 尝试修复 sudo sqlite3 /var/lib/syncthing/index.db PRAGMA integrity_check; # 如果输出不是 ok则重建 sudo rm /var/lib/syncthing/index.db sudo restart syncthing # Syncthing 会自动生成新库6.6 链路六权限链断裂permissionerror(13, 连到系统上的设备没有发挥作用。)这个错误看似是串口问题实则是 Syncthing 尝试访问/dev下的设备节点失败。在 Trusty 上