[Samba] Mac OSX clients - slow display & copy times with image files

[Nathan A Friedl]

On Fri, Jul 15, 2011 at 09:09:58PM +0000, Nathan A Friedl wrote:
>> We've been having intermittent problems with our Mac OS clients and our file servers.  We've had a few reports of 10.6.x clients opening folders (usually consisting of image files) and having the Finder hang for an extended period of time before it finishes displaying the files.  Additionally, when trying to copy a number of image files into another folder, I have witnessed it hang for 10+ minutes before starting the copy.

>> A little more information on our setup:  We have 2 RHEL 4u6 file servers, kernel version 2.6.9-100 x86_64 running samba 3.5.8.  They are pulling users and groups from our Windows 2003 Domain controller.  The 10.6.x clients that have been reporting problems are bound to our domain and a Mac OS 10.5 server we use for workgroup management.
>>
>> The samba logs for the client haven't revealed anything obvious to us (and are chock full of noise since the Macs insist on reading the metadata of everything in a folder when the folder is opened), but the log.winbindd-idmap log displays the following, which we are interpreting to mean that the system may be temporarily unable to map the SID to the uid:
>>
>> [2011/06/03 11:35:09.940054, 10] winbindd/idmap_ad.c:581(idmap_ad_sids_to_unixids)
>>   Filter: [(&(|(sAMAccountType=XXXXXXXX)(sAMAccountType= XXXXXXXX)(sAMAccountType= XXXXXXXX)(sAMAccountType= XXXXXXXX)(sAMAccountType= XXXXXXXX))( |(objectSid=\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX\XX)))]
>>
>> [2011/06/03 11:35:09.940598,  1] winbindd/idmap_ad.c:651(idmap_ad_sids_to_unixids)
>>   Could not get unix ID

>Look at the difference between these timestamps: 0.000544 seconds.
>This is not the 10+ minutes difference you're looking for :-).

>Try running wireshark and seeing if you can see what is going
>on on the wire when you're seeing the 10+ minutes delay on the
>client. The good news is this is so bad that it should be easy
>to spot what is going on during this time.
>
>Jeremy.

Thanks Jeremy, we'll see what wireshark can tell us.  We haven't been able to reliably reproduce the problem, but we'll see what we can do.  In the meantime, if there's any information that you think might be useful in diagnosing the problem, please let me know.

Regards,
Nathan