Another Snow Leopard NAS SMB issue. Directory delay.

Same problem here on both a macbook pro and an imac. But only when connected through ethernet. If I go wireless, everything is fine. This is weird.

No issues with Pathfinder. So it is a bug with the Finder.

actually a finder issue for long long time.
I hoped it would be fixed in 10.6; but unfortunately it isn't.

I really think Apple should have enhanced finder in terms of functionality in 10.6.

I too am experiencing this delay with 10.6 when connecting via smb and ethernet to a windows server. Seems to be a longer delay for folders containing more items. I have some folders with 300 images each 2MB and finder takes around 20 seconds to display contents (spins in corner until it displays). This did not happen prior to 10.6

I also experience the directory delay when accessing shares on a Windows 2003 Server.
With 10.4, I had to type "sysctl -w net.inet.tcp.delayed_ack=0" to speed up the network transfer. It worked well to speed up the connection speed but has no influence on the time needed to show the directory.

For me it's especially slow when connecting via VPN.

Same problem. Definitely a new problem with 10.6 or maybe 10.6.1, not carried over from 10.5. Will try wireless instead of Ethernet and report back.

UPDATE: I'll be ******, the problem is gone when connecting using wireless, rather than Ethernet. Weird, but this result should allow the underlying problem to be identified and resolved more quickly.

Message was edited by: nolamike

Connecting via wireless has solved the delay issue with our fileserver running Solaris (and using the SMB protocol). However, I have another server running Linux, and that one still has issues. The root contents are listed fine. Try to view any subfolder, and you get a perpetual spinning status indicator (in lower right of Finder window.) Terminal displays the contents of such directories with no delay (using ls command), so the problem seems to remain with the Finder.

Here's to 10.6.2 coming along soon and resolving all this. I hope it will happen. Having issues with basic access to your files is distressing.

OK, more troubleshooting data. I tried browsing the Linux volume in question (see previous post) with the dock -- click my dock icon of the drive to display the pop-up grid of folders, then click on a folder to drill down -- works fine. Meanwhile in the background, a regular Finder window is grinding away* to no avail... So this problem is very Finder specific.

Help us, someone...

* spinning status indicator in lower right, file listing blank.

Same problem here since 10.6 with different versions of samba on linux, the issue occurs with samba 3.0.x, 3.2.x, 3.3.x and 3.4.x.

I would also confirm it's a finder issue. While finder is delayed, other finder windows will also stall on the same smb share, while console and dock folder browsing still works.

OK, here's the latest. following a tip on macwindows.com, I checked out the veto files parameter in smb.conf on our Linux server. As expected, the was an entry for .DS_Store files (so these files can be hidden from Windows users). I edited the entry to no longer veto .DS_Store and restarted samba. Boom, problem is gone!

Now, back to the Solaris server. To reiterate: with this server, I do get directory contents listed reliably, but often only after a wait of 10 secs or more.
I turned off my wireless "workaround" connection, where delays are not apparent, and went back to Ethernet. Found a directory that exhibited the delay. Went in on the command line, deleted the .DS_Store file, unmounted the volume from the Finder, remounted, tried to open the directory--instant file listing. Tried this procedure a couple more times to be sure, and I get the same result. If a .DS_Store file gets re-created fresh after deletion, and I unmount and re-mount the volume, I get the delay again.

So, both problems on both servers, which I had started thinking were similar but unrelated, seem to in fact be related, and linked to .DS_Store files. I believe that Solaris (we are using the kernel-integrated SMB/CIFS) does not have a veto-files parameter. Will investigate with my sys admin.

I have similar issue with 10.4.11. When I browse shared volume on a Synology NAS, I had experienced long delay, with both AFP and SMB connection.

It looks like Finder had treat extended file attribute in different way in 10.4, 10.5 and 10.6. Following this message:
http://ja.wikipedia.org/wiki/AppleSingle#netatalk
(Those informations are not available in English version)
It says:

"After 10.4 Tiger, the extended-attribute is added to the system. The Finder will store extended information with AppleDouble format, that is, files with names started by '._'. This also means that the compatibility with original AppleDouble had been dropped.

"From 10.5, extended attribute will not be preserved when access some legendary remote file system, like old AFP server. However, in 10.6, the '._' files will be created on these servers to store the extended attribute."

In other words, it's quite possible that 10.5 users will experience some kind of problems with remote file server when they upgrade to 10.6.

In my case I've found that the Synology deals with AppleDouble in different ways: they're creating a "@eaDir" directory within each directory as a storage for ANY meta data, including the Mac resource folk, the Windows thumb.db, and preview databases generated by Synology's Photostation service.

I solved my problem by switching to NFS connection.

Possibly there's multiple issues or causes for this.

I have 'com.apple.desktopservices DSDontWriteNetworkStores' set to true, so .DS_Store files don't even exist on my network shares.

Just switched it off (default) to see if it makes a difference, and it does not.

Also the behaviour here seems sporadic and it's never related to a certain folder or server. The 2 samba servers I connect to have similar configurations though, eg. running in security mode 'ads', idmap backend 'rid' and having acls on ext3.