记一次TimeMachine配置小坑

请注意,本文编写于 196 天前,最后修改于 196 天前,其中某些信息可能已经过时。

TimeMachine.png
TimeMachine.png

过去一段时间,家里路由配置一直是“主iKuai,旁koolshare”组合。这个组合已经稳定工作有2年多时间。

由于koolshare维护状态已经进入“濒死”阶段,为保障家里网络服务稳定,于是决定对这路由系统进行改造。

简单研判了一下,决定选择”主ROS,旁openWRT“方案。

母机是PVE,这样搭配很速度就撸出来。为节省资源,我把原来omv主机删掉,把MacOS的备份系统直接转移到openWRT上。

按照官方提供的配置方案顺利部署好AFP服务器。不过问题来了。无论我使用MacOS的网络模块还是用ssh的方式连接openWRT的afp能连接,但是无法验证登录。

检查了afp的log文件,没有发现异常。琢磨半天是不是类似SMB协议那样需要有个用户账户转换问题。翻遍AFP的官方文档,没能找到解决方案。

谷歌爬文半天也未能找到解决方案。准备重做omv之际,我重新看了一下afp的log文件,发现登录过程只记录了很简单的一句:

{afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 0.06 KB read, 0.06 KB written}

然后查找AFP文档发现默认的log等级比较简单,没有记录debug内容于是修改afp.conf文件的log level:

[Global]
; Global server settings
log file = /var/log/afpd.log
log level = default:maxdebug uamsdaemon:maxdebug afpdaemon:maxdebug
afp interfaces = br-lan

再次测试登录afp,然后查看log文件发现问题所在:

PAM DHX2: libgcrypt versions mismatch
由于libgcrypt缺失,造成无法使用PAM验证登录。

在ssh中直接执行

   opkg update && opkg install libgcrypt

片刻安装成功,重启afp,并重新测试登录afp。这次,密码验证成功,顺利登录。

最后测试MacOS的TimeMachine备份也正常了。

这我也是看不懂,比我的折腾的高深多了...

看不懂,解决问题就好

有点好深,留个角印就跑路

kool­sharer的确不好,我之前iKuai+kool­share,用着挺好的,一时手贱搞成单kool­share了,现在又懒得重新装。

换。原版的openwrt功能强大太多了