hwclock -w 失败主因是 chrony 用户无权访问 /dev/rtc0：默认权限仅 root 可读写，需创建 rtc 组、将 chrony 加入该组，并通过 udev 规则（SUBSYSTEM=="rtc", GROUP="rtc", MODE="0664"）持久化设置属组与权限，再配合 SELinux 策略（chronyd_use_rtc=1）及 systemd 服务配置检查。
chronyd 同步后 hwclock -w 失败：常见报错和权限根源
直接现象是执行 hwclock -w 时提示 Cannot access the Hardware Clock via any known method 或 Permission denied，即使 chronyd 已成功同步系统时间。根本原因不是 chronyd 配置问题，而是 hwclock 访问 RTC 设备（通常是 /dev/rtc0）时缺乏权限 —— 默认情况下该设备节点只允许 root 或 rtc 组成员读写。
/dev/rtc0 权限不足：检查与修复步骤
先确认当前设备节点权限和所属组：
ls -l /dev/rtc*
典型输出为：crw------- 1 root root 254, 0 Apr 5 10:22 /dev/rtc0 —— 这表示只有 root 可访问。chronyd 默认以 chrony 用户运行，无法写入 RTC。
- 确保内核已启用 RTC 支持（
CONFIG_RTC_CLASS=y，通常默认开启） - 创建
rtc组（如不存在）：sudo groupadd rtc - 将
chrony用户加入rtc组：sudo usermod -a -G rtc chrony - 修改
/dev/rtc0的属组和权限（需在 udev 规则中持久化）：
新建/etc/udev/rules.d/85-rtc-permissions.rules，内容为：SUBSYSTEM=="rtc", GROUP="rtc", MODE="0664" - 重载 udev 并触发规则：
sudo udevadm control --reload-rules && sudo udevadm trigger --subsystem-match=rtc
chronyd 配置中启用硬件时钟写入的条件
仅改权限还不够 —— chronyd 必须被明确配置为“同步后写回 RTC”。它不会自动调用 hwclock -w，而是通过自身机制完成。
- 确认
/etc/chrony.conf中启用了rtcsync（内核级同步，不写 RTC）或makestep+hwclock调用逻辑 - 真正触发写 RTC 的是
makestep指令配合hwtimestamp或显式使用hwclock脚本；但更常用且推荐的是启用rtcsync并配合 udev 权限，让内核自动维护 RTC 偏移（无需用户态写入） - 若坚持用
hwclock -w，建议在 chronyd 同步后由 systemd timer 或 cron 触发，而非依赖 chronyd 自身 —— 因为 chronyd 不提供 post-sync hook - 验证是否生效：
sudo -u chrony sh -c 'hwclock -w && echo ok'，应无报错
SELinux 或 systemd 服务沙箱导致的隐性拦截
即使权限和组设置正确，仍失败？很可能是 SELinux 策略或 systemd 服务限制阻止了 chronyd 访问 /dev/rtc0。
- 检查 SELinux 拒绝日志：
sudo ausearch -m avc -ts recent | grep chronyd，若出现avc: denied { read write } for ... dev="rtc0"，需添加策略：sudo setsebool -P chronyd_use_rtc 1 - 检查 chronyd 服务是否启用了
RestrictAddressFamilies或NoNewPrivileges，这些会限制设备访问；可在/usr/lib/systemd/system/chronyd.service或覆盖文件中注释或调整 - 重启服务并验证：
sudo systemctl daemon-reload && sudo systemctl restart chronyd
RTC 写入失败往往卡在权限链最末端：设备节点权限 → 用户组归属 → udev 规则持久性 → SELinux 上下文 → systemd 安全限制。漏掉任意一环，hwclock -w 就会静默失败。
