10.5.2, NFS and extended attributes

I too have this problem with 10.5.2.
I have a nfs server running opensuse10.3.

When I mount the nfs disk using the finder...
nfs://192.168.0.100:/mnt/data/temp

What I can do:
1) Read all files
2) Create new directories
3) Copy files from the Finder, which don't have extended attributes
4) Copy files from the command line, which don't have extended attributes.

What I cannot do:
1) Copy files from the Finder, which have extended attributes
--> Finder responds with 198.168.0.100 disconnected
--> Finder shows error -36, -35, -1024?
2) Copy files from the command line, which have extended attributes.
--> cp vlc.dmg /Volumes/192.168.0.100/.
--> command line responds with...
nfs server 192.168.0.100:/mnt/data/temp:lockd not responding
--> Finder responds with 198.168.0.100 disconnected

When I look at my opensuse PC, the nfs disk shows...
._vlc.dmg (size?)
vlc.dmg (0KB)

Any suggestions?

I filed a bug report on this. It has morphed into three.

Things got worse with 10.5.2 -- this is now happening with other apple NFS-mounted filesystems as well as linux now.

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). I have four 10.5 Intel Macs. 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. Since I generally accept security updates without a second thought, I had also installed one the same day.

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. When I checked sure enough, 10.5.2 was not installed but the new security update was.

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.

So I'm currently pointing my finger at the security update, which coincidentally appears to contain a patch for NFS. Whatever it is, it's utterly broken my PHDs, so I'd really like to see it addressed.

Any trackable bug information would be a plus.

I have a server running Ubuntu 7.2 Server.

I just upgraded one of our Mac workstations to 10.5.2. Now NFS fails with the error "Server connection interrupted" when trying to mount through the finder (cmd + K).

However when I run the mount command from the terminal I am able to connect AND browse the NFS mount only through the terminal. However, when mounting through the terminal and then trying to go to the window via the finder (using cmd + shift + G) I get the same error.

A second workstation running 10.4.11 works just fine.

I found that mounting the NFS mount with -o nolocks fixed the issue with regards to extended attributes. It does seem to be a locking issue; if I omit this, I get:
nfs server ... lockd not responding
Of course, I verified that it's running using rpcinfo but I suspect that any operation that uses locking will fail, and the extended attributes happen to be one of them.

Yes, it's clearly a problem talking to the lockd service, but may not be limited to EAs. In the course of filing an extremely detailed bug report with Apple, including many network traffic dumps, I found that I was getting syslog entries complaining about lockd not responding a little while after the "cp -X" operation completed.

What's really weird is that for a while last weekend it worked just fine, including EAs just as it should, then went back to the broken behavior. I was unable to find any correlatable pattern to explain it working for a few hours.

Message was edited by: corbaguy

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. 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).

The basic problem is that the NAS is not responding to lockd RPC requests. Further investigation seems to show that some degredation occurs as the NAS runs - having just rebooted, it all works fine. 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. Manually running "/sbin/rpc.lockd" [not surprisingly] 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. "rpcinfo -p" also shows all of the NFS-related services, including nlockmgr, as being available.

The NAS and client are as follows:

merlin:
Model: ReadyNAS NV (X-RAID)
Serial: ****
Firmware: RAIDiator 4.01c1-p1 (1.00a041)
Memory: 256 MB (2.5-3-3-7)
- - - -
Addons: SSH, APT
Packages: tcpdump 3.8.3, libpcap 0.8.3

orthrus:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.6 GHz
Memory: 4 GB
- - - -
ProductName: Mac OS X
ProductVersion: 10.5.2
BuildVersion: 9C31

The two chat happily over GigE (no jumbo frames):
orthrus # traceroute -vnS -P UDP -q 5 merlin
traceroute to merlin. **, 64 hops max, 40 byte packets
1 192.168.42.3 48 bytes to 192.168.42.39 0.777 ms 0.265 ms 0.125 ms 0.122 ms 0.122 ms

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:

This is a follow-up to Bug ID# 5784942.

Engineering has provided the following feedback regarding this issue:

Looking at the traces:

2008.03.09_15.23.20-apple.5784942-nps0.pcap.client
2008.03.09_15.23.16-apple.5784942-nps0.pcap.server

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. However, there is no indication of any response being attempt - either on the client's side or the server's side. That would indicate that there's a problem with the server's lockd. The client is asking the server what port lockd is running on, the reply is port 3075, and the requests from the client are going to port 3075.

2008.03.09_15.29.30-apple.5784942-ns0.pcap.client and
2008.03.09_15.29.27-apple.5784942-nps0.pcap.server
show the same.

2008.03.09_15.34.36-apple.5784942-ns0.pcap.server and
2008.03.09_15.34.40-apple.5784942-ns0.pcap.client
show the same.

2008.03.09_15.42.20-apple.5784942-ns0.pcap.server and
2008.03.09_15.42.22-apple.5784942-ns0.pcap.client
show the same.

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. There's not much the client can do in this situation.

You will need to figure out what's wrong with the server's lockd, or perhaps seek support from Infrant/NetGear. Either it's registered on the wrong port, it's no longer running, or it's hung/unresponsive for some reason.

We consider this issue closed. Thank you for taking the time to notify us of this issue.

Corbaguy,

I've been looking at Netgear ReadyNAS NV+ to set up a RAID file server on my home office network. I heard about the file time stamp issue with Mac OS 10.5.2 users and spoke to Netgear tech support. They have a fix for the problem that is available as a download from their web site.

Below is the email that I received today regarding the issue and the fix. I'm looking to hear from ReadyNAS owners here that it works before I buy one.

Cheers, Bud James

Bud,

Here is the response I got from engineering:

Here is some info that might clear things up.

When we were shipping our 3.01c1-p6 release (2.4 kernel) we used a
version of Netatalk that handled AFP well but it did not have all the
latest patches. When we switched over to the 2.6 kernel we included an
updated Netatalk with all the latest patches. We ran through a beta
cycle with our users and all seemed well. We later discovered that the
time stamp on most file transfers were not being preserved. This caused
all types of strange errors. We now have a AFP patch on the forum that
we offered to users to help with their time stamp issue and the results
have been very positive. All the issues they were reporting were now
fixed. This new Netatalk update will be included in our new release and
if users need this fix now they can download the add-on from the forum.

http://www.readynas.com/forum/viewtopic.php?f=28&t=16836

In the future all updates and new add-ons that are available will be
passed on to our L3 teams so that when any one with questions about
certain issues can get the latest info if any on the subject. If anyone
has any further questions feel free to ask me or Justin.

Thanks,
Albert


So go ahead and purchase away!

Derek Falberg
Sr.VAR Sales Engineer
Netgear, Inc.
(408) 907-8116
www.netgear.com
derek.falberg@netgear.com

Bud,

My issue has been with NFS, not AFP. I haven't had troubles with AFP, but I don't use it very much due to character mapping and permission issues that are simply characteristics of the protocol, not bugs.

The ReadyNAS folks are looking into the issue, and I expect they'll fix it sooner rather than later (they seem to be very prompt), but it does appear to be something to do with Linux in general as opposed to ReadyNAS in particular.

Other than this issue, which I expect to be resolved soon, I've been quite happy with the ReadyNAS, though there are some competitive units on the market now that I'd look into if I were shopping now.