![]() There's not much the client can do in this situation. ![]() So, the problem appears to be that the NFS server is advertising that it's lockd is running on port 3075, but requests being sent to that port on the server are not getting any responses. ![]() That would indicate that there's a problem with the server's lockd. However, there is no indication of any response being attempt - either on the client's side or the server's side. It clearly shows that LOCK_MSG requests are being sent to the server and the server's capture file shows that the requests are making it to the server. I have provided quite a collection of detailed documentation and network traces, but the response from Apple (edited down to the pertinent bits) sums it up nicely:Įngineering has provided the following feedback regarding this issue:Ģ008.03.09_15.23.Ģ008.03.09_15.23. The two chat happily over GigE (no jumbo frames): "rpcinfo -p" also shows all of the NFS-related services, including nlockmgr, as being available. Manually running "/sbin/rpc.lockd" doesn't fix the problem I haven't tried re-registering with portmap but, as shown below, portmap is still showing it available to the client. Past experience suggests that locking will stop being responsive sometime in the next 24 hours or so, and will not come back until the NAS is rebooted. Further investigation seems to show that some degredation occurs as the NAS runs - having just rebooted, it all works fine. The basic problem is that the NAS is not responding to lockd RPC requests. In my case that server is an Infrant ReadyNAS, but the common characteristic of the servers mentioned here is that they're all Linux (the current ReadyNAS firmare uses a modified _Linux 2.6.17.8_ SPARC kernel). I have gotten a response back from Apple regarding my bug report, and they point squarely at my NFS server as the source of the problem. Whatever it is, it's utterly broken my PHDs, so I'd really like to see it addressed.Īny trackable bug information would be a plus. So I'm currently pointing my finger at the security update, which coincidentally appears to contain a patch for NFS. The symptoms are as described here, and since the FileSync daemon tries to sync the extended attributes as well (and can't), the end result is that PHDs are hosed. When I checked sure enough, 10.5.2 was not installed but the new security update was. ![]() My wife has instructions to accept Apple updates when they pop up on her iMac, and when I told her not to accept the 10.5.2 update because it seemed to cause trouble she told me she was having the same problem I was having on the MBP. Since I generally accept security updates without a second thought, I had also installed one the same day. When I upgraded the first one (MBP) from 10.5.1 to 10.5.2 everything related to NFS pretty much broke, including my Portable Home Directories, which I attributed to the update. ![]() I'm not sure it's 10.5.2, I think it could be the security update that came out the same day (I believe it's 2008-001). ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |