Another Snow Leopard NAS SMB issue. Directory delay.

I am sure it is something with the extended attributes being stored on the server. There must have been a change from 10.5 to 10.6. I had the problem on Samba and Windows file shares, the finder taking a LONG time to enumerate directly listing and file listing. I believe (have not proved it yet) simply browsing the directory once in 10.6 updates things and fixes it. If you go to the top level folder in your share with list view (where the directories have the little triangle) do a "command" tipdown of the triangle will expand all subdirectories in the path. This seems to update the extended attributes to 10.6 "style". Tried unmounting the volume and remounting. It does permanently fix it. I suspect any new directories created on a non-10.6 machine and accessed from a 10.6 machine would have the same problem.

New update. Scrap everything I said. It does NOT seem to be persistent. Furthermore, I manually did a command line find "*.DS_Store" -delete to remove any of the Desktop Services Store files, remounted and the problem still existing for me. I suppose once a directory listing is done in the finder, it gets cached, which is why is appeared to be fixed. Sorry for the confusion.

Here is a little known tip to speed up SMB transfer rates with OSX.

1. open a terminal
3. sudo sysctl -w net.inet.tcp.delayed_ack=0

Mount your SMB drive and try a file Xfer to see if it speeds up.

Just Google MAC OSX tcp delayed ack smb and look at the hits.

@DrVenture: this issue isn't about transfer rates, so the param change won't help.

Hi Glyn!

Yesterday it took me 8 hours of smb.conf editing, finally to find out what you already discovered: _Snow Leopard cannot deal with Samba shares having some veto files configured._

But here is a difference: Using Pathfinder, even with a terminated finder, the browser windows hangs up, too. But most time, I tried it with finder windows. Sometimes they never come back (never > 5 minutes). Path finder responded to some requests with some error messages concerning some files ending with "-Spotlight".

I don't know what your situation is. Currently, my mac is unusable, as I cannot access to the network files - and that's where my content is!

See also: http://www.macwindows.com/snowleopard-filesharing.html

I am new on support.apple.com. How can we proceed in this case? I didn't find a possibility to file a bug. Did anyone already file one? If yes, can we vote/track it some where?

Oh what to **** are they doing ... spamming every media I plug into my Mac. I have a USB stick with 60.000 source code files. Everytime plugging it into the mac, it starts indexing it. This takes more than 10 minutes, wasting space and life time of the stick. So please tell me: is this really a feature, or is it a bug ... ?

With best regards,

Holger

@holger: the problem discussed here does not seem to have anything to do with veto files and it's been reported to only occur in finder and not in any other application (like pathfinder)

So I would assume your issue is an entirely different one.

Thank you for your quick answer. There was an original question: What has changed between 10.5 and 10.6 in accessing to SMB shares. I tried to participate to the answer to this question.

The document behind the link I posted lets me assume that this is a complex thing, where nearly everything can be related to nearly everything. I hardly can say if it is technically related to each other. But let me try to explain the relation there is for me: The imporant question is: _Does apple want to support professional SMB file shares_, or is SMB support just a marketing feature, mabye useful for some standard users at home? In other words: Is apple interested in reports in the intetion to make Mac OS X SMB access compatible and stable. I really would like to hear apple wants to support it for professional usage.

I do work professionally with the Mac computer, but if apple won't fix the SMB file share access, I would be forced to change my hardware - what I don't want(!), of course.

Thank you, I think you may be right that it is not technically related. That's why I ask _how to proceed_ with that complex (urgent) thing "SMB-access" in general.

I didn't try it yet, but seems you can submit bug reports here.

Thank you. I will have a look.

Yesterday I tested file browsing with the finder once more, and the finder window didn't came back for 10 hours. I had to restart the computer this morning. As you reported, browsing with command line for example works fine. That's why I was looking for special things that only the finder does - like writing .DS_Store etc.

I just filed a bug report for it now (Problem ID: 7344039).

Well it was never longer than like half a minute on my side. Is finder completely frozen in this state?

In the course of optimizing smb throughput I added a few socket options to the smb.conf of my servers.

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536

Since then I couldn't actively replicate the delay problem, but it could still be coincidence.
Can anyone confirm this setting improves the situation?

Sorry for the delay.

In my case, finder hangs forever (>10 hours). I figured out that resolve that problem by deleting the following line from the smb.conf:

veto files = /.DS Store/.*/.TemporaryItems/Thumbs.db/.AppleDouble/.bin/.AppleDesktop/Network Trash Folder/. Spotlight/.Trashes/.fseventd/

Of course after that, the SMB file system is spammed by the Macs with the listed files (. *,.DSStore and so on), that's why the IT administrator won't remove it.

I have this problem on a WD Sharespace (with latest firmware and software updates as of November 2009) using SMB and this is in a professional environment. All workstations are iMac 2.66 Ghz with 4GB's RAM and 640GB hard drives.

I've just been reading the many different discussions online about this issue and can't find any discussions that have a resolution. I was hoping 10.6.2 would fix this, but no.

I can't believe this is just a problem sitting out there with no resolution. Apple can't advertise SMB in 10.6.2 if it takes minutes just for finder to display a directory and that is what I'm seeing on MANY of my directories. Some directories have 200 word docs, some directories have 1000 word docs. It does seem that the amount of files affects the speed of browsing, but not always the same.

i.e. my 860 file directory took 20 seconds to load and my 260 file directory took close to 5 minutes. This is inversely relational...

PLEASE SOMEONE HELP!!!!! THIS IS RIDICULOUS!!!!

I experienced the same problem with shares exported from my OpenSolaris server. As previously reported, two possible workarounds helped - either switch from Ethernet to Airport or from SMB to NFS. For performance reasons, I chose the latter. However, the performance is also suboptimal. Even with dumb ftp transfer I measure 20 MByte/s through Gigabit ethernet from the OpenSolaris server to the OSX client. Same transfer in the opposite direction is three times faster. I have no explanation for this.
Furthermore, restoring server backups with "zfs receive" from OSX smb exports fail with a deadlock error, whereas they work well when the backup files are exported via nfs.

Cheers
Markus