NAS on 魔都水滴

你的照片其实一份都没有：NAS 不是备份，3-2-1 才是最后的安全感

Wed, 29 Jul 2026 08:00:00 +0800

先说结论

如果你的照片只存在于手机、电脑和同一台 NAS 上，那么它们很可能不是三份备份，而是同一份数据的三个入口。手机丢失、NAS 被勒索、同步误删、房屋进水时，这三个入口可能一起失效。

真正值得记住的不是“买一台更贵的 NAS”，而是 3-2-1：至少 3 份数据、至少 2 种介质、至少 1 份异地副本。再往前一步，就是 3-2-1-1-0：增加 1 份离线或不可变副本，并且恢复校验错误为 0。

RAID 不是备份！群晖、飞牛、Unraid 到底怎么选，别等硬盘坏了才看懂

Sat, 11 Jul 2026 12:00:00 +0800

先说结论

RAID 的主要任务，是在一块或几块硬盘故障时，让 NAS 尽量继续工作；备份的主要任务，是在文件被误删、被勒索软件加密、NAS 被偷、主板损坏或房屋发生意外后，把数据找回来。两者都重要，但绝不是一回事。

如果你用群晖，家庭用户通常优先考虑 SHR-1，硬盘多、容量大且数据重要时考虑 SHR-2；如果你用飞牛 fnOS，应把“文件系统、存储模式、硬盘数量和备份位置”一起决定，而不是只看 RAID 名称；如果你用 Unraid，则要先理解它不是传统条带化 RAID：每块数据盘保留独立文件系统，校验盘负责故障恢复，混盘与扩容更灵活，但写入性能、校验规则和备份责任也完全不同。

最简单的选择法是：两盘选镜像思路，三到五盘且容量优先选单盘冗余，六盘以上或单盘容量很大时认真考虑双盘冗余；不可重下的数据，无论选什么 RAID，都再做一份异地或离线备份。

密码没写错，群晖却不让登录？我拆开 DSM 的 RSA + AES 双层信封，完整复刻 WebAPI 登录

Sat, 11 Jul 2026 08:30:00 +0800

先说结论

群晖某些 WebAPI 登录请求并不是简单地把 account 和 passwd 直接提交给 auth.cgi。OpenStack Cinder 的 Synology 驱动展示了一套完整兼容流程：先调用 SYNO.API.Encryption.getinfo，取得 RSA 公钥、服务器时间和两个动态字段名；客户端生成一次性随机 passphrase，用 RSA 加密它，再用它派生 AES-256-CBC 的密钥和 IV，对 URL 编码后的登录参数加密，最后把两段 Base64 密文放入服务器指定的 cipherkey 字段。

但必须先划清边界：这是一种 WebAPI 身份认证兼容方式，不是破解密码，也不是绕过权限；拿到 session=DSM 的 API SID，也不等于凭空获得浏览器 DSM 管理页面的完整 Cookie 登录状态。HTTP 参数加密同样不能代替 HTTPS，因为 TLS 还负责服务器身份校验、完整性保护和抵抗中间人攻击。

别被“飞牛盘 / Btrfs盘”骗了：超低价硬盘背后的 SMR 坑

Thu, 09 Jul 2026 10:00:00 +0800

先说结论

机械硬盘不是只看容量和价格。CMR 像正常车道，随机写入比较稳定；SMR 像屋顶瓦片，一层压着一层，容量更高，但改一小块数据时可能要重写一整片区域。更麻烦的是，SMR 还分 硬盘自己管理的 SMR 和 主机必须配合管理的 SMR。最近 PDD 上一些超低价大容量盘被包装成“飞牛盘”“Btrfs盘”，听起来像 NAS 神盘，实际很可能是 host-managed SMR 企业退役盘。它不是完全不能用，而是非常挑系统、挑文件系统、挑写入模式。普通 NAS、Windows 桌面、黑群晖、ZFS/RAID 混用场景，基本不推荐碰。

我的购买建议很粗暴：看不到准确型号，不买；查不到厂商 datasheet，不买；Linux 下 queue/zoned 显示 host-managed，普通用户不买；卖家只强调 Btrfs/飞牛/低价，却不说 SMR 类型，不买。

别再半夜抢遥控器了：用 DSM 计划任务给群晖儿童视频目录自动上锁

Sun, 05 Jul 2026 06:50:00 +0800

先说结论

这次不是“禁用孩子账号”，而是只给群晖里的一个儿童视频目录定时上锁。做法是在 DSM 7.2.1 上准备一个 kid_video_guard.sh，到点用 synoacltool 给目标目录加一条临时 deny ACL，开放时间再把这条 ACL 删除。账号、密码、家庭相册、作业目录都不动，只有“儿童视频”这个柜门到点关上。

群晖把我的 root 锁在门外三道，我花了二十分钟把它教会

Thu, 18 Jun 2026 16:30:00 +0800

TL;DR（先说结论）

群晖（Synology DSM）为了安全，默认把 SSH 关掉、还禁止 root 直接登录——这是好事，别骂它。这篇文章就是带你"按规矩"把门打开：

控制面板 → 终端机和 SNMP → 启用 SSH（把大门打开）

用普通账户登录 + sudo -i 切到 root（先去物业借钥匙）

修改 /etc/ssh/sshd_config 里 PermitRootLogin yes（跟门卫说"root 是自己人"）

synouser --setpw root xxx 设密码 + 把公钥写到 ~/.ssh/authorized_keys（换一把永远不会丢的钥匙）

全程大约二十分钟，比想象简单。我会把每一步都用"钥匙和锁"的比喻讲清楚，再附上 vi 编辑器三秒钟入门、常见报错和 Q&A。

把「该睡觉了」搬出客厅：让 mac 的 launchd 每天 22:00 自动停用群晖孩子的账号，08:00 再悄悄启用

Sun, 14 Jun 2026 08:20:00 +0800

先说结论

群晖 DSM 控制台里其实有一个"停用账号"按钮，但它不会自动按时执行。借助 mac 自带的 launchd 加一段 50 行的 bash 脚本，可以做到：每天 22:00 把孩子的两个本地账号 expired 标志置位，08:00 再恢复。脚本自带"改前查询 → 改 → 改后查询"的三步校验，任何一步对不上号立刻 exit 1，launchd 会把执行日志写进 StandardOutPath/StandardErrorPath。整件事的特别之处是**“家长"两个字被从对话里拿掉了**——你不用每天喊"该睡了”，机器会准时替你做。

本文不打算讲一个大而全的家庭 NAS 管理方案，只围绕一件具体的事：让一个原本靠"人记得点"的操作，变成"到了点就自动发生"的纯系统级动作。

如果你只想先看图，第二节那张「晚 10 点断电 / 早 8 点复电」的总览图就够了。

PhotoPrism 启动 5 分钟还在装系统包？一次 PHOTOPRISM_INIT=intel 的踩坑与正确配置

Sat, 13 Jun 2026 08:30:00 +0800

TL;DR（先说结论）

PhotoPrism Plus 镜像的 docker-compose.yml 里有一行 PHOTOPRISM_INIT: "intel"，看似只是给 Intel 核显开加速，实际上它在容器第一次启动时会去 archive.ubuntu.com 跑一次完整的 apt-get dist-upgrade，再装 7 个 GPU / VA-API 包。这套流程 5–10 分钟起步，整个期间容器内部没有任何进程在监听 2342 端口。你的 docker ps 显示 Up、Portainer 一切绿、ss -ltn 也看到 0.0.0.0:2342 在 LISTEN——但浏览器一访问就是 ERR_CONNECTION_RESET / Connection reset by peer。

解法非常简单：删掉或清空那一行。你 devices 里已经挂上 /dev/dri/renderD128 直通，驱动和 VA-API 用户态工具由宿主机提供，容器里再装一遍是纯浪费。

一块希捷 IronWolf Pro 突然告警，我从 SMART 体检到 RMA 换新的全流程

Sat, 13 Jun 2026 08:00:00 +0800

先说结论

群晖发来一条「硬盘 10 坏扇区数已增加」告警，看着吓人，但真正在坏的不是那块盘，而是另一个槽位的希捷 IronWolf Pro 10TB；而那块故障盘恰好是台版，还在保，我把它从 SMART 体检、故障分类、台版转保、邮件文案到包装寄出，全部走通了一遍。这篇就把这条完整路径写下来，留给以后哪天再遇到同样告警的自己，也给同样用 NAS 的人一点参考。

先交代一下背景：家里这台 NAS 是一台群晖（DS3617xs + DSM 10），常年 7×24 小时跑，里面装了 4 块 10TB 的机械盘，分别来自西部数据（两块白盘）、HGST（Ultrastar He10 氦气盘）和希捷（IronWolf Pro 10TB）。这次告警出现之前，整个系统已经稳定跑了快三年。

【转】ImmortalWrt 旁路由安装与配置

Mon, 11 May 2026 21:10:55 +0800

这篇文章转载自 Egg Targaryen 的《ImmortalWrt旁路由安装与配置》，原文采用 CC BY-NC-SA 4.0 许可发布。本文保留原文的操作顺序与截图，并按本站排版做了轻微格式调整。

ProxmoxVE 添加 local-lvm 使用率监控、网线速率监控到 Uptime Kuma

Tue, 05 May 2026 17:20:00 +0800

先说结论

ProxmoxVE 的 local-lvm 不是一个普通挂载目录，很多时候不能靠 df -h 发现它快满了；网口协商速率也不会因为服务还在线就自动暴露出来。最稳的办法是把这两个“容易被忽略但一出事就很麻烦”的指标接入现有 Uptime Kuma：local-lvm 用 HTTP 拉取监控，网口速率用 Push 主动上报。这样磁盘池接近阈值、网线或交换机端口掉到百兆时，统一在 Uptime Kuma 页面和通知链路里告警。

本文会从需求背景、原始方案的问题核查、改进后的脚本、systemd 服务、Uptime Kuma 配置、验证方法和安全边界讲完整。文中所有地址、token、主机名都使用占位符，不出现真实内网信息。你可以把示例里的 <PVE_HOST>、<KUMA_URL>、<PUSH_TOKEN>、<INTERFACE> 替换成自己的环境值。

给 OpenClaw / HermesAgent 集成群晖操作 SKILL：从一句话到可审计的 NAS 自动化

Tue, 05 May 2026 12:20:00 +0800

我之前已经整理过两篇偏“命令手册”风格的群晖文章：

这两篇文章解决的是“人知道有哪些命令可以用”的问题。本文想解决另一个更实际的问题：如果我已经在使用 OpenClaw / HermesAgent 这类 Agent 工具，能不能把这些群晖命令沉淀成一个操作 SKILL，让我以后用一句话就能让 Agent 帮我检查 NAS、整理状态、生成操作计划，甚至在确认后执行一些维护命令？

我的答案是：可以，但不应该把它做成“Agent 拿到 root 权限以后随便跑”。正确的集成方式应该是：

让群晖 SSH 访问可控、可验证、可撤销。
把常用群晖 CLI 操作写进 SKILL，让 Agent 知道可用命令、风险分级和输出格式。
默认只允许只读诊断命令自动执行。
对重启服务、修改权限、改用户、改网络、删除文件、存储相关操作设置确认门禁。
每次执行后保留命令、输出和结论，方便回看和追责。

如果你只想快速理解整篇文章，看下面这张图就够了。

【转】群晖NAS CLI管理指南

Thu, 30 Apr 2026 18:20:04 +0800

本文档包含命令行工具，使应用程序能够利用群晖DiskStation上的资源，同时包含群晖错误代码参考列表。

【转】Synology DiskStation Administration CLI Guide 官方文档导读与命令速查

Thu, 30 Apr 2026 18:14:05 +0800

先说结论

Synology 这份官方 CLI 管理指南并不是一本面向普通 DSM 图形界面用户的入门手册，而是一份给脚本、自动化和系统集成场景准备的命令参考。它覆盖了 DSM 中最常见的几类管理动作：本地用户、本地群组、共享文件夹、网络配置、服务控制、工作组或 ADS 域设置，以及错误码查询。

这篇文章是基于 Synology 官方 PDF《CLI Administrator Guide for Synology NAS》整理的中文导读和命令速查。由于原 PDF 属于 Synology 官方版权文档，本文不会全文复制或逐段翻译原文，而是按博客阅读习惯重新组织成一份便于检索、理解和日常运维使用的双语整理稿。需要逐字核对参数定义、版本差异或法律声明时，请直接阅读文末的官方 PDF 来源。

给 NAS 挂上 speedtest 子域名，为什么有时能快一大截？

Fri, 24 Apr 2026 09:00:00 +0800

先说结论

如果你家里的 NAS 外网访问一直被限速，而你又恰好能控制自己的域名和反代入口，那么把入口子域名改成带 speedtest 的形式，确实有机会明显改善体验。
这不是魔法，也不是绝对规则，更像是命中了某些运营商对“测速相关流量”的放行或弱限制策略。

我参考了飞牛私有云论坛上的一篇讨论，原帖的核心观点很直接：家庭宽带有时会对普通外网访问做比较明显的策略性限速，但如果访问目标在域名里带了 speedtest，链路表现就可能突然变得宽松很多。本文不复述那篇帖子里的口吻，而是把这个思路整理成一篇更适合长期保存的博客笔记，重点回答三个问题：

这个办法为什么可能有效
具体应该怎么落地
什么情况下它不会生效，或者不值得折腾

Docker 容器太多导致网段冲突：把自动分配网络统一迁回 172 私有段的完整记录

Mon, 13 Apr 2026 08:00:00 +0800

这篇文章记录的是一次很典型、也很容易被忽略的 Docker 网络故障：容器越来越多，Docker 自动分配出来的 user-defined bridge 网段，最后落进了 192.168.x.x，并且和家里的真实局域网发生了冲突。问题本身不算复杂，但它有一个很讨厌的特点：它不是那种“容器起不来”或者“端口没映射”的显性错误，而是把整个家庭网络拖进一个很别扭的半瘫痪状态。

当时在我的 NAS 上，家里部分设备开始出现访问异常。表面上看，像是某个设备离线，或者某个交换机、AP、路由器出了毛病；但我沿着 Docker 的网络一路排查下去后，最终确认，真正的根因不是单个容器坏了，而是 Docker 网络池的自动分配策略，已经把局域网挤到了一个危险的位置。

论Mac电脑和TimeMachine的重要性

Tue, 14 Sep 2021 16:55:10 +0800

今天是2021年9月14日。

到今天为止，我已经使用 MacOS 作为主力系统，已经有了2年左右的时间。

不得不说，我现在已经深深的爱上了 MacOS。如果我需要购买下一台笔记本，我一定会购买 MacBookPro高配。

基于 PVE + 软路由 + NAS的家里网络架构梳理（面向技术人员）

Fri, 03 Sep 2021 09:50:49 +0800

家庭网络概述

家庭网络，不会像正规的虚拟化平台那样，搞『业务平面』『管理平面』『数据平面』三个平面分离。家庭网络需要的是方便，那么上面说的三个平面，就需要融合在一起共用网络，才能管理方便。家庭网络的安全也十分重要，谁也不希望家里的网络大门就一直对外敞开着。

准备硬件设备

电信光猫（目前只有电信宽带，才有可能要到公网IP）
多网口工控机（软路由，性能不要太差）
普通台式机或服务器（能保证7x24小时开机就行）
AC + AP（AC 和 AP需要同一个品牌，考虑到 5G WIFI 穿墙性能极差，建议每个房间都配1个5G AP）
NAS（建议白裙或黑裙）
网线
U盘
可插网线的笔记本电脑（配置网络用）

中国电信，如何找客服申请公网IP

Mon, 25 Jan 2021 22:12:32 +0800

目前国内的三大运营商中，也就中国电信的公网IP最富裕了。但是随着全球IPv4资源彻底耗尽，地主家也没余粮了。

如何使用群晖（DSM）运行N2N-编译篇

Fri, 15 Jan 2021 13:18:07 +0800

群晖（后面使用DSM代替）是一个目前最著名的NAS系统，没有之一。如何在DSM上直接运行N2N呢，当然又需要交叉编译了😂。下面的交叉编译操作，需要有Linux的基本功，和vim操作的基本功。