好吧,我简直要疯了。
尝试设置 OS X (10.8.2) NFS 客户端以连接到 Debian (6.0.6) nfs 服务器。我主要遵循以下说明:https://help.ubuntu.com/community/NFSv4Howto非常详尽。但是,有两个问题:
- 当我不使用 Kerberos,性能很差(我认为一定是超时了),而且所有文件显然都属于 nobody:nobody。对
ls
已安装的目录执行一次操作需要几十秒。 - 当我做尝试使用 Kerberos,为服务器和客户端创建主体,我无法挂载共享。客户端抱怨:
mount_nfs: can't mount /mnt from servername.domain onto /home: Permission denied
我已经设置了两个主体,nfs/servername@REALM
和nfs/clientname@REALM
,并复制到/etc/krb5.keytab
客户端和服务器上。
该服务器(根据 Kerberos 日志)正在获取票证,nfs/servername.REALM
因此我怀疑 OS X NFS 客户端没有以某种方式使用其主体。
有任何想法吗?
更新: /var/log/daemon.log
报告:
Oct 7 19:12:43 servername rpc.svcgssd[19635]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure. Minor code may provide more information - No supported encryption types (config file error?)
根据此页面:http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/5551我删除了客户端和服务器 krb5.keytab 文件中除 DES 加密选项之外的所有选项。并allow_weak_crypto
在/etc/krb5.conf
文件中添加了这些选项。然后重新启动hfs-kernel-server
,它仍然不起作用。唉。
事实上,现在有报道称:
Oct 7 19:26:55 servername rpc.svcgssd[19721]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure. Minor code may provide more information - Wrong principal in request
“请求中的主体错误”是否意味着客户端传递了错误的 krb5 主体?我可以在 OS X 中控制它吗?
答案1
NFSv4 在 Mac OS X 10.8 下似乎相当不完善。
非官方消息称,Apple 已意识到此问题,但尚未确定修复时间表。同时,大家一致认为 opendirectoryd 相当不完善。
您可以检查以下几个地方以获取更好的调试信息:
# sysctl -w vfs.generic.nfs.client.idmap_ctrl=127
/var/log/system.log
在尝试运行命令时 观察输出ls
。# odutil set log debug
观察输出/var/log/opendirectoryd.log
用来
dtrace
找出挂断的位置。
我们的经验是,这是nfs4_id2guid
因为 opendirectoryd 并不总是正确地在内核中注册自己而导致超时。
答案2
我认为您应该尝试创建另外两个主体,并将您的域名添加到您的服务器名称中。
喜欢nfs/mysername.example.com@REALM
和host/myclientname.example.com@REALM
但无论如何,在 MacOSX 上,您必须在尝试安装之前拥有 TGT。
因此,在挂载之前尝试 kinit(任何主体都可以)。
就我个人而言,我设法在 MacOSX 上拥有 nfs+kerberos。但在 NFSV3 中。
在 NFSV4 中我设法安装它,但它很慢......非常慢。