分类： 互联网应用

家人无法备份到 Mac 共享 Time Machine 文件夹的一次排查记录

MacBook 通过网络共享目录备份到家庭服务器的 Time Machine 备份示意图

最近在整理家里的 Mac mini 服务器时，遇到一个和 Time Machine 网络备份有关的问题：Mac mini 上已经有一块专门给自己使用的 Time Machine 磁盘，也开启了文件共享，但家人的 MacBook 无法正常把备份写入这个共享位置。

一开始看起来像是普通的 SMB 共享权限问题：共享文件夹已经加上了，用户也给了“读与写”，但客户端还是无法创建 Time Machine 备份。排查以后发现，真正的问题不在共享面板，而在这个卷本身已经被 macOS 当作本机 Time Machine 目标管理。

当时的配置

Mac mini 上已有一个 Time Machine 目标卷：

  • 名称：timemachine；
  • 类型：本地磁盘；
  • 挂载点：本机 Time Machine 目标卷；
  • 文件系统：APFS；
  • 加密状态：已加密；
  • 配额：4 TB。

这个卷是给 Mac mini 自己做 Time Machine 备份用的。因为它容量比较大，所以直觉上会觉得：既然已经有一个 Time Machine 磁盘，把它共享出来，让家人的 MacBook 也往里面备份，应该也可以。

但这个思路实际并不稳妥。

表面现象：共享权限看起来没问题，但就是写不进去

在 macOS 的“文件共享”里，可以给某个共享目录设置用户权限，比如“只读”或“读与写”。如果只看这一层，很容易误判为：只要给家人的用户设置了“读与写”，对方就应该能备份。

但 Time Machine 网络备份不是普通文件复制。客户端需要在目标位置创建备份包，并持续写入大量快照数据。只要底层目录不允许创建文件或文件夹，哪怕 SMB 共享面板显示“读与写”，备份也会失败。

关键原因：Time Machine 卷根目录有系统保护 ACL

排查时发现，本机 Time Machine 目标卷 根目录存在一条系统 ACL，大意是禁止添加文件、删除文件、添加子目录、删除子项和修改属性。

deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

这条规则很关键。它意味着这个卷根目录不是一个普通的数据目录，而是被 macOS 按 Time Machine 目标卷来保护。即使是管理员账号，也会受到这条规则影响。

所以这次问题的核心结论是：共享面板里的“读与写”只是 SMB 共享层权限，不能覆盖 APFS 卷根目录上的 Time Machine 保护 ACL。

为什么不建议共用同一个 Time Machine 卷

把 Mac mini 自己正在使用的 Time Machine 卷再共享给家人的 MacBook，有几个问题：

  • 这个卷已经被 Mac mini 本机 Time Machine 服务管理；
  • 卷根目录有系统保护规则，不适合作为普通共享目录；
  • 多个设备混用同一个目标位置，后续容量、权限和故障排查都会变复杂；
  • 如果误操作删除或修改内容，可能同时影响 Mac mini 自己的备份。

Time Machine 备份目标最好职责单一。Mac mini 自己用一个目标，家人的 MacBook 用另一个目标。即使它们在同一块物理硬盘上，也应该通过不同 APFS 卷或专用文件夹隔离开。

推荐方案：给家人单独建一个 APFS 卷

更稳妥的方案，是保留当前 timemachine 卷只给 Mac mini 自己使用，然后在同一块外置硬盘或同一个 APFS 容器里，新建一个单独给家人使用的 APFS 卷。

例如可以新建一个卷：

卷名：家人专用备份卷
用途：家人 MacBook 的网络 Time Machine 备份目标

然后按下面方式配置：

  1. 不要把这个新卷添加为 Mac mini 自己的 Time Machine 目标；
  2. 在“系统设置 -> 通用 -> 共享 -> 文件共享”里共享这个新卷；
  3. 给家人的本地用户设置“读与写”；
  4. 进入共享项目的选项，开启“共享为时间机器备份目的位置”；
  5. 按实际磁盘空间设置备份大小上限，比如 1000 GB 或 1500 GB；
  6. 在家人的 MacBook 上重新选择这个网络备份目标。

这样做的好处是很直接：Mac mini 自己的备份和家人的网络备份互不干扰，权限也更清楚，后续如果要扩容、限制容量或排查问题，也不会互相牵连。

如果不想新建 APFS 卷怎么办

如果暂时不想新建 APFS 卷，也可以在普通数据卷里创建一个专用文件夹，只把这个文件夹共享为 Time Machine 目的位置。

但我更倾向于独立 APFS 卷。原因是 APFS 卷更适合做容量隔离，也更容易看懂用途。尤其是家庭服务器长期运行后，目录和共享项会越来越多，清晰的卷名比藏在某个普通文件夹里的备份目录更容易维护。

排查时还遇到的权限提示

这次排查过程中，命令行读取某些备份目录时还出现过 macOS 权限拦截，例如 Operation not permitted。这类提示通常和 macOS 隐私权限、完全磁盘访问权限、Time Machine 后台服务状态有关。

如果只是配置家人的网络备份，优先不要陷入这些系统级问题。先把备份目标拆分清楚：Mac mini 自用卷归 Mac mini，自家人备份卷归网络 Time Machine 共享。结构清楚以后，再去处理具体服务报错会简单很多。

我的检查顺序

以后再遇到家人无法备份到 Mac 共享 Time Machine 文件夹，我会按这个顺序检查：

  1. 确认共享目标是不是 Mac mini 自己正在使用的 Time Machine 卷；
  2. 确认目标目录是否存在 Time Machine 保护 ACL；
  3. 不要只看 SMB 共享面板里的“读与写”；
  4. 检查该用户在 Mac 本机是否能真正创建文件和文件夹；
  5. 给家人单独准备 APFS 卷或专用文件夹；
  6. 在共享选项里启用“共享为时间机器备份目的位置”；
  7. 设置合理的备份容量上限；
  8. 在家人的 MacBook 上重新选择新的网络备份目标。

小结

这次问题的教训是：Time Machine 目标卷不是普通共享文件夹。即使 SMB 共享层显示“读与写”，底层 APFS 权限和 Time Machine 保护规则仍然可能阻止客户端创建备份。

家庭服务器里的备份配置，最好从一开始就分清用途。Mac mini 自己的 Time Machine 卷只给本机使用；家人的 MacBook 单独使用一个网络 Time Machine 共享目标。这样结构更清楚，权限更稳定，也更不容易在以后维护时误伤已有备份。

Windows 无法通过 SMB 访问 Mac 共享文件夹的一次排查记录

Windows 电脑通过局域网访问 Mac 共享文件夹的 SMB 文件共享排查示意图

最近在给家里的 Mac mini 做文件共享配置时，遇到一个很典型的问题：Mac 这边已经开启了文件共享，也能看到共享文件夹，但 Windows 电脑就是无法通过 SMB 正常访问。

这个问题表面上看像是“Windows 连不上 Mac”，实际排查下来，往往不是单一原因，而是 SMB 服务、共享权限、macOS 用户权限、Windows 凭据缓存和网络地址这几层叠在一起造成的。本文记录这次排查思路，方便以后遇到类似问题时按顺序检查。

问题现象

当时的目标很简单：在 Windows 电脑上访问 Mac mini 共享出来的文件夹，用它作为家庭服务器的一部分，方便在局域网内传文件、整理下载内容和访问外接磁盘。

Windows 端尝试访问的方式一般是：

\\Mac的内网地址
\\Mac的内网地址\共享名称

但实际表现可能是下面几种：

  • Windows 提示无法访问网络路径；
  • 能弹出用户名和密码输入框，但输入后仍然失败；
  • 能看到 Mac，但打不开具体共享文件夹；
  • 同一台 Windows 电脑之前能连，后来突然不能连；
  • Mac 本机看起来权限正常，但 Windows 端始终没有读写权限。

第一步：确认 Mac 的文件共享是否真正开启

先从 Mac 端开始检查，不要一上来就在 Windows 里反复输入密码。

在 macOS 里进入：

系统设置 -> 通用 -> 共享 -> 文件共享

这里要确认三件事：

  • 文件共享已经打开；
  • 目标文件夹已经加入共享列表；
  • 右侧用户权限里，准备用来登录的用户至少有“只读”或“读与写”权限。

很多时候问题就出在这里：Mac 只是开启了“文件共享”，但目标文件夹并没有加入共享列表，或者共享列表里有这个文件夹，但登录用户没有权限。

第二步：确认 SMB 已经对指定用户启用

Windows 访问 Mac 文件共享走的是 SMB。macOS 的文件共享打开以后，还需要在选项里确认 SMB 共享用户。

检查位置是：

系统设置 -> 通用 -> 共享 -> 文件共享 -> 信息按钮 -> 选项

在这里要确认：

  • “使用 SMB 共享文件和文件夹”已经打开；
  • 准备用来从 Windows 登录的 Mac 用户已经勾选；
  • 这个用户的密码是已知且可用的。

这一点很容易漏掉。共享文件夹权限里出现某个用户，并不等于这个用户已经被允许通过 SMB 登录。Windows 端输入的应该是 Mac 上已启用 SMB 的本地用户和密码。

第三步：不要只看共享权限，还要看磁盘和文件夹本身权限

macOS 文件共享有两层权限：一层是共享面板里的权限，另一层是磁盘和文件夹本身的文件系统权限。Windows 能不能访问，最终要同时通过这两层。

例如一个外接硬盘、APFS 卷或特殊用途目录，即使在共享面板里设置成了“读与写”，也可能因为文件夹本身权限、系统保护 ACL 或 Time Machine 管理状态而无法写入。

所以我会在 Mac 本机上先做一个简单验证：用同一个用户登录 Mac，直接在目标文件夹里新建一个测试文件。如果 Mac 本机这个用户都不能写入，那么 Windows 通过 SMB 也不可能正常写入。

第四步：Windows 端使用正确的登录格式

Windows 访问 Mac 共享时，用户名最好明确写成 Mac 本地用户名，不要依赖 Windows 自动补全。可以尝试下面几种形式：

Mac用户名：专用账号电脑名\Mac用户名：专用账号内网IP\Mac用户名

其中最关键的是：密码要用 Mac 这个本地用户的登录密码，而不是 Apple ID 密码，也不是 Windows 账户密码。

如果之前输错过用户名或密码，Windows 可能已经缓存了错误凭据。这种情况下即使 Mac 端已经改好了，Windows 仍然会继续用旧凭据登录，表现出来就像 Mac 还没修好。

可以在 Windows 的“凭据管理器”里删除与这台 Mac 相关的记录，然后重新连接。

第五步：优先用 IP 地址测试，不要先依赖电脑名

局域网里通过电脑名访问，有时会受 NetBIOS、mDNS、路由器或 Windows 网络发现影响。为了减少变量，排查时我更建议先用 Mac 的内网 IP 地址测试。

在 Mac 上查看当前内网 IP 后，在 Windows 资源管理器地址栏输入：

\\内网地址

如果 IP 可以访问，但电脑名不能访问，说明 SMB 服务本身大概率没问题，问题更可能在名称解析或网络发现上。后续可以再处理电脑名访问，但不要把它和 SMB 权限问题混在一起。

第六步：确认两台设备在同一个局域网

这一步看似基础，但家庭网络里很常见。Windows 电脑和 Mac mini 可能分别连到了不同网络，比如主 Wi-Fi、访客 Wi-Fi、手机热点、Mesh 的隔离网络，或者不同路由器下面的子网。

如果 Windows 和 Mac 不在同一个网段，或者路由器开启了访客网络隔离，Windows 就可能完全访问不到 Mac 的 445 端口。

排查时可以先确认两台设备的 IP 地址是否类似：

Mac:     内网地址
Windows: 内网地址

如果一个是 192.168.1.x，另一个是 192.168.50.x，就要先回到路由器和网络连接上排查。

第七步：重启 SMB 服务或重新开关文件共享

当权限、用户和网络都确认无误后，如果 Windows 仍然连不上，可以在 Mac 上关闭“文件共享”，等待几秒后再重新打开。必要时重启 Mac。

这一步不是玄学。SMB 共享配置、用户启用状态、外接磁盘挂载状态发生变化后，服务端有时需要重新加载配置。对家庭服务器来说，重启前最好确认没有正在进行的文件复制或备份任务。

我最后采用的检查顺序

以后再遇到 Windows 无法访问 Mac SMB 共享，我会按下面顺序处理：

  1. 确认 Mac 文件共享已开启；
  2. 确认目标文件夹已加入共享列表；
  3. 确认共享用户有读写权限；
  4. 确认 SMB 选项里已勾选这个用户；
  5. 在 Mac 本机验证该用户能否读写目标文件夹；
  6. Windows 端删除旧凭据后重新登录；
  7. 优先用 Mac 内网 IP 访问，而不是电脑名；
  8. 确认 Windows 和 Mac 在同一个局域网；
  9. 重新开关文件共享，必要时重启 Mac。

小结

Windows 无法通过 SMB 访问 Mac 共享文件夹时，不要只盯着用户名密码。真正稳定的排查方式，是把问题拆成四层：Mac 是否开启 SMB、用户是否允许通过 SMB 登录、目标文件夹本身是否允许访问、Windows 是否用了正确凭据和正确地址。

对家庭服务器来说，文件共享最好保持简单清晰：固定 Mac 的内网 IP，使用专门的本地共享用户，只共享必要目录，并避免把系统保护目录或 Time Machine 目标卷直接当作普通共享目录使用。这样后续 Windows、Mac 和其他设备访问起来都会更稳定。

在 Mac mini 上配置 qBittorrent 的一次整理记录

Mac mini 上配置 qBittorrent 下载管理、队列和安全访问的示意图

最近在整理家里的 Mac mini 服务器时，也把 qBittorrent 的使用方式重新梳理了一遍。相比临时在主力电脑上下载，把下载器放到一台长期在线的 Mac mini 上，更适合处理大文件、长时间任务和家庭影音资料整理。

这篇文章记录一下配置思路：下载目录怎么规划，Web UI 为什么要谨慎开放，权限和磁盘怎么处理，以及哪些设置更适合长期运行。出于安全考虑，文中不写真实 IP、端口、账号、完整路径或具体目录名。

为什么把下载器放到 Mac mini 上

下载任务有一个特点：它不一定需要人一直盯着，但需要设备长期在线。如果下载器跑在笔记本或主力电脑上，电脑休眠、关机、换网络都会影响任务。

Mac mini 更适合承担这个角色。它功耗低、可以长期运行，也能连接大容量外接磁盘。下载完成后，文件可以直接留在家庭服务器的数据盘里，再通过局域网共享给其他设备访问。

先规划下载目录

配置 qBittorrent 前，最先要想清楚的不是速度，而是目录结构。下载目录如果一开始随便放，后面会很难整理。

我更倾向于把目录分成几类：

  • 临时下载目录：正在下载、尚未完成的文件；
  • 完成目录：已经下载完成、等待整理的文件；
  • 分类目录：按影音、资料、软件等用途归档；
  • 监控目录：用于自动导入种子文件。

临时目录和完成目录分开有一个好处：媒体库、共享目录或后续整理工具不会过早扫描到未完成文件。下载完成后再移动到正式位置，整体更干净。

确认磁盘和权限

qBittorrent 需要持续写入磁盘，所以目录权限必须先确认。不能只看文件夹是否存在，还要确认运行 qBittorrent 的用户是否能真正创建、修改和删除文件。

如果下载目录在外接硬盘或单独数据卷上，还要注意两点：第一，磁盘要稳定挂载；第二，系统休眠或磁盘睡眠不要影响下载任务。否则 qBittorrent 可能会出现任务报错、文件丢失或重新校验。

我一般会先手动在目标目录里创建一个测试文件，再删除它。这个动作能快速确认当前用户是否具备基本读写权限。

Web UI 只建议在可信网络里使用

qBittorrent 的 Web UI 很方便，可以在其他电脑或手机上管理下载任务。但它也属于管理后台，不应该裸露到公网。

更稳妥的做法是：

  • 只在局域网内访问 Web UI；
  • 设置强密码，不使用默认账号密码；
  • 不要把 Web UI 端口直接映射到公网；
  • 如果确实需要外网管理，优先通过 VPN、SSH 隧道或其他安全入口访问。

下载器后台一旦暴露，风险不只是别人添加下载任务，还可能影响本机磁盘、网络带宽和内部文件。家庭服务器里任何管理页面，都应该默认只给可信网络访问。

连接和速度设置

qBittorrent 默认设置可以用，但如果放在长期运行的服务器上，最好根据家里宽带情况做一点限制。

我会重点关注这些设置：

  • 全局上传速度限制；
  • 全局下载速度限制；
  • 最大连接数；
  • 每个任务最大连接数；
  • 同时下载和同时做种的任务数量。

上传速度尤其要留余量。如果上传被占满，家里其他设备打开网页、视频通话、远程访问都会变慢。更好的策略是给 qBittorrent 一个稳定但不过分的上传上限，让它长期跑，而不是短时间把网络打满。

分类和标签要早点用起来

下载任务多了以后，只靠默认下载目录会很乱。qBittorrent 支持分类和标签，建议从一开始就用起来。

分类适合决定文件保存位置，比如影视、资料、软件、临时任务。标签更适合描述任务状态，比如待整理、长期做种、已归档。这样以后查找任务、移动文件和清理旧任务都会轻松很多。

自动导入种子文件

如果经常从其他设备添加任务，可以准备一个监控目录。把种子文件放进去以后，qBittorrent 自动导入任务，不需要每次打开 Web UI 手动添加。

这个方式适合局域网共享使用：其他电脑只要能把种子文件放到监控目录，Mac mini 上的 qBittorrent 就会自动接管下载。目录权限同样要提前确认，避免文件放进去了但 qBittorrent 读不到。

完成后移动和校验

下载完成后的文件，不建议一直混在临时目录里。可以设置完成后移动到指定目录，或者手动根据分类整理到最终位置。

如果文件保存在外接磁盘上，偶尔遇到异常断电、磁盘断开或系统重启，任务可能需要重新校验。重新校验虽然花时间，但比直接删除重下更可靠。长期运行的下载器，要接受“校验是维护的一部分”。

不建议直接公网开放下载器后台

很多人配置下载器时，会顺手把 Web UI 端口映射到公网，觉得这样手机在外面也能管理任务。但对家庭服务器来说，这不是一个好习惯。

下载器后台应该和路由器后台、NAS 后台一样，被当作敏感管理入口。即使设置了密码，也不建议直接暴露。需要远程管理时，应该先进入可信网络，再访问内部服务。

我的配置检查顺序

以后重新配置 qBittorrent，我会按这个顺序检查：

  1. 确认 Mac mini 长期在线，网络和磁盘稳定；
  2. 规划临时目录、完成目录和分类目录；
  3. 确认下载目录的读写权限；
  4. 开启 Web UI，但只允许可信网络访问；
  5. 设置强密码，避免默认配置；
  6. 根据宽带情况设置上传、下载和连接数限制；
  7. 启用分类、标签和监控目录；
  8. 测试添加任务、下载完成、文件移动和重新校验；
  9. 确认不会把下载器后台直接暴露到公网。

小结

qBittorrent 本身不难装，真正需要花心思的是长期运行配置。目录结构、磁盘权限、Web UI 安全、速度限制和任务分类，这些细节决定了它后面是一个稳定的下载中心，还是一个越用越乱的临时工具。

放在 Mac mini 这类家庭服务器上使用时，我更看重可维护性：目录要清楚，后台不要公网裸露，上传不要占满，任务要能分类，出了问题能通过日志和状态看明白。这样下载器才能真正成为家庭服务器的一部分。

Mac mini 连不上 Wi-Fi 的一次排查记录

现象

这次问题的表现大致是:

  • Mac mini 无法稳定连接家里的 Wi-Fi；
  • 远程连接不稳定，或者直接连不上；
  • 依赖局域网 IP 的服务可能失效；
  • 外网入口虽然有域名和端口转发，但内网主机本身离线后也无法访问；
  • 如果 Mac mini 正在承担备份、共享或下载任务，这些任务都会受到影响。

这种问题容易误判。表面看是 Wi-Fi 问题，但实际需要同时检查三层:

  1. Mac mini 本机有没有连上网络；
  2. 路由器有没有给它分配正确的内网地址；
  3. 依赖这个地址的服务是否仍然指向正确主机。

第一步: 先确认是不是 Wi-Fi 本身的问题

遇到网络问题时，我现在会先避免直接改系统配置，而是先确认范围。

可以先检查这些点:

  • 手机、笔记本是否能正常连接同一个 Wi-Fi；
  • Mac mini 是否能看到目标 Wi-Fi 名称；
  • 是否只有 Mac mini 连不上，还是所有设备都受影响；
  • 2.4GHz 和 5GHz 网络是否都异常；
  • 路由器是否刚刚重启、升级或修改过配置。

如果其他设备都能正常上网，问题大概率在 Mac mini 本机或它与路由器之间的连接状态。如果所有设备都异常，就应该先检查路由器、光猫或宽带，而不是继续折腾 Mac mini。

第二步: 检查 Mac mini 当前网络状态

Mac mini 连不上 Wi-Fi 时，最直观的检查位置是:

系统设置 -> Wi-Fi

重点看几个信息:

  • Wi-Fi 是否已打开；
  • 是否已经连接到正确的网络；
  • 是否出现“无 IP 地址”“自分配 IP”之类的提示；
  • 是否反复连接又断开；
  • 是否误连到访客网络、热点或旧路由器名称。

如果 Wi-Fi 已连接，但仍然无法访问局域网或外网，可以继续看:

系统设置 -> Wi-Fi -> 详细信息 -> TCP/IP

这里主要确认:

  • IP 地址是否属于家里路由器的网段；
  • 路由器地址是否正确；
  • DNS 是否为空或异常；
  • 是否拿到了一个奇怪的自分配地址。

如果 IP 地址不是路由器分配的正常地址，就算 Wi-Fi 图标显示“已连接”，实际网络也可能不可用。

第三步: 忘记网络后重新连接

如果确认只有 Mac mini 有问题，一个有效办法是让 macOS 忘记这个 Wi-Fi，然后重新输入密码连接。

路径通常是:

系统设置 -> Wi-Fi -> 已知网络 -> 找到当前网络 -> 忘记此网络

然后重新选择 Wi-Fi，输入密码连接。

这一步可以解决一些缓存配置问题，比如旧密码、旧认证信息、异常的网络配置残留等。它比盲目重启更有针对性，也比直接重置所有网络设置更温和。

第四步: 重启网络设备和 Mac mini

如果忘记网络后仍然不行，我会按这个顺序重启:

  1. 重启路由器；
  2. 等 Wi-Fi 完全恢复；
  3. 再重启 Mac mini；
  4. 重新连接 Wi-Fi。

顺序很重要。先让路由器稳定下来，再让 Mac mini 获取地址，可以减少 DHCP 分配异常、路由器刚启动时连接失败等问题。

如果家里有多个路由器、Mesh 节点或无线中继，还要确认 Mac mini 实际连接的是哪个节点。有时候设备连到了信号弱的节点，表面在线，实际丢包严重。

第五步: 确认固定 IP 或端口转发没有被影响

对家庭服务器来说，Wi-Fi 恢复只是第一步。真正要确认的是服务有没有恢复。

我的 Mac mini 有外网访问配置，路由器上也做了端口转发。如果 Mac mini 重新联网后拿到了不同的内网 IP，原来的端口转发就可能失效。

因此 Wi-Fi 恢复后，还需要检查:

  • Mac mini 当前内网 IP 是否仍然是预期地址；
  • 路由器端口转发是否仍然指向这台 Mac mini；
  • SFTP、远程维护等服务是否能从局域网访问；
  • DDNS 是否还在正常更新；
  • 从外网测试域名和端口是否可达。

一个常见坑是: 在家里 Wi-Fi 下测试外网域名，可能会受到路由器内网回环能力影响。更稳妥的测试方式是让手机关闭 Wi-Fi，使用蜂窝网络测试，或者让另一台电脑连接手机热点再测试。

第六步: 如果还是不行，再考虑系统层面

如果前面的步骤都没有解决，才需要继续排查 macOS 系统层面的问题，例如:

  • 删除并重新添加 Wi-Fi 服务；
  • 检查是否开启了 VPN、代理或安全软件；
  • 检查 DNS 是否被手动设置成不可用地址；
  • 更新 macOS；
  • 进入恢复模式或安全模式做进一步确认。

但这些步骤影响面更大，不建议一开始就做。多数家庭网络问题，其实在“忘记网络、重启路由器、重新获取 IP、检查端口转发”这几个环节就能定位。

这次问题给我的提醒

这次 Mac mini 连不上 Wi-Fi，让我重新意识到一件事: 家庭服务器最好不要完全依赖无线网络。

如果条件允许，Mac mini 作为长期在线设备，最好使用有线网口连接路由器。相比 Wi-Fi，有线连接有几个明显好处:

  • IP 更稳定；
  • 延迟和丢包更少；
  • 不受无线信号、Mesh 漫游和频道干扰影响；
  • 更适合 Time Machine、文件共享、远程访问这类长期服务；
  • 路由器端口转发和固定地址配置更可靠。

如果暂时只能使用 Wi-Fi，也建议至少做两件事:

  1. 在路由器里给 Mac mini 绑定固定内网 IP；
  2. 记录一份网络恢复检查清单。

我的检查清单会是:

  • 确认其他设备是否能正常联网；
  • 确认 Mac mini 是否连到正确 Wi-Fi；
  • 查看 Mac mini 是否拿到正确内网 IP；
  • 忘记 Wi-Fi 后重新连接；
  • 重启路由器和 Mac mini；
  • 检查路由器固定 IP 和端口转发；
  • 用手机蜂窝网络测试外网访问；
  • 最后再考虑 macOS 系统级重置。

总结

Mac mini 连不上 Wi-Fi，看起来是一个小问题，但如果它承担了家庭服务器职责，影响会被放大。排查时不要只盯着 Wi-Fi 图标，而要按链路一步步确认: 本机连接、IP 分配、路由器配置、服务可用性、外网访问。

这次记录的最大价值，是把排查顺序固定下来。下次再遇到类似问题时，就不用靠感觉处理，而是按清单一步步排除。

对家庭服务器来说，稳定性往往比功能更重要。能用有线就尽量用有线；如果必须用 Wi-Fi，就要把固定 IP、路由器配置和外网测试方法都提前准备好。

VPS 磁盘占用莫名上涨？我是这样把 Debian 11 的 journal 日志限制住的

最近排查一台新加坡节点的小 VPS，发现硬盘占用总是在慢慢往上爬。WordPress 文章、媒体库、MySQL binlog 都排除之后，最后锁定了一个很容易被忽视的来源：systemd 的 journal 日志。

这类日志不是博客内容，也不是 AMH 面板自己的日志，而是 Debian 系统层的运行日志。像 SSH 登录尝试、定时任务、服务状态变化，都会被写进去。如果服务器挂在公网，日志增长速度往往比想象中快。

我这台机器一开始查到的结果是：

journalctl --disk-usage

输出显示：

Archived and active journals take up 440.0M in the file system.

对于一台 40G 硬盘的小 VPS 来说，440M 已经没必要了。解决思路也不复杂：给 journald 设置上限，再把旧日志压缩回收。

journal 是什么

先简单说一句，避免混淆。

  • amh-access.log、nginx access.log 这类，是面板或网站自己的日志
  • journal 是 Debian 系统自己的总日志池，由 systemd-journald 管理

它通常会记录这些内容：

  • SSH 登录和爆破尝试
  • CRON 定时任务
  • 服务启动、重启、报错
  • 内核和系统消息

所以你在 auth.log 里看到一堆 Invalid user admin、Invalid user ubuntu 的同时，journal 里通常也会同步增长。

修改 journald 限制大小

直接编辑配置文件：

nano /etc/systemd/journald.conf

在 [Journal] 下面加入这几行：

[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day

这几个参数的意思很直白：

  • SystemMaxUse=80M：磁盘上的 journal 总占用尽量控制在 80M 左右
  • RuntimeMaxUse=30M：运行时日志占用控制在 30M
  • SystemMaxFileSize=20M：单个日志文件不要太大
  • MaxRetentionSec=7day：最多保留 7 天

这套数值对小内存、小硬盘的 VPS 比较合适。不是绝对标准，但足够实用。

让配置生效

保存后执行：

systemctl restart systemd-journald

然后把旧日志清理到目标范围：

journalctl --vacuum-size=80M

如果想更激进一点，也可以改成：

journalctl --vacuum-size=50M

检查结果

执行：

journalctl --disk-usage

我这台机器处理完后的结果是：

Archived and active journals take up 96.0M in the file system.

虽然不是精确等于 80M，但这是正常现象。SystemMaxUse 更像一个控制目标，不是硬切到一字不差。只要从几百 MB 降下来了，而且后续不再无限增长，目的就达到了。

再顺手确认一下配置是否写进去了：

grep -Ev '^\s*#|^\s*$' /etc/systemd/journald.conf

如果输出类似下面这样，就说明已经生效：

[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day

这一步能解决什么问题

限制 journal 后，至少能解决两件事：

第一，系统日志不再无上限吃盘。

第二，后面再排查磁盘占用时，能把注意力放回真正异常的目录，而不是一直被系统日志干扰。

不过也要说清楚：限制 journal 只是收口，不是治本。

如果你的服务器像我这台一样，公网不断有人扫 SSH 端口，那 auth.log 和 journal 还是会继续写，只是不会再失控。所以更彻底的做法，通常还包括：

  • 修改 SSH 默认端口
  • 禁止密码登录
  • 只允许密钥登录
  • 安装 fail2ban

最后

如果你也在用 Debian 11 或类似的 systemd 系统，发现 VPS 磁盘占用总是缓慢上涨，先别急着怀疑网站内容或者数据库。

先看一眼：

journalctl --disk-usage

很多时候，问题就藏在这里。