Bound Macs not connecting to Windows servers via SMB (error -36)

The first thing to do is check that the time on the sever and clients are in sync. If it is more than 5 min out- Kerberos authentication fails. Generally the clients will see an "error -36" when this happens.

If the clients continue to have problems you might have to make adjustments to the security settings on the Windows server. If it is a server which is bound to IPGEMEA you will have to get the Directory Team to make GPO changes for you.

Here is a solution from the Apple discussion boards:

I just finished battling this on a large (200+ Macs) heterogenous network with Windows Server 2003 and Windows Server 2008 domain controllers / file servers.

To use SMB connections with Windows 2003 servers on 10.4 you must first disable SMB packet signing on the server. To do this I think you must... (Props to nmonkee for description on another thread)
To disable SMB signing:

Open Default Domain Controller Security Settings.
Go to Security Settings, Local Policies, security Options.

Disable the following:

Domain member: Digitaly encrypt or sign secure Channel Data (Always)
Microsoft network server: Digitally sign communications (Always)
Microsoft network server: Digitally sign communications (If client agrees)

To refresh the policy:

from a command prompt run gpupdate

Doing this alone did not solve my problem with 10.4.11 Macs connecting. Now they could connect, but the shares appear 'empty'. To solve this I had to permit the user/group to List Folder Contents in the security tab when looking at the share properties.

Once I made this change, the structure and contents of the share was visible, and all other permissions were working properly.

*Note - if the destination share is inside another share, all shares all the way down to the root share must have List Folder Contents active for all 10.4 users, all the way up to the destination share. This can be controlled with individual user permissions or with a specific group for tighter security.
The end result of this type of solution is that if a group of users has List Folder Contents privileges for a root share all the way down to an individual share, they can see the directory structure of the root share all the way down to their destination share, but cannot see the files inside any directory but their own.

Prior to these changes, 10.5 could not connect via SMB, but then after disabling SMB packet signing on the Windows 2003 server, 10.5 could navigate the shares properly. The permissions fix is only for 10.4, and possibly earlier.

I am connecting to SMB this way:
Go Menu>Connect to server...>smb:///the/share/path
Then authenticating against Active Directory.
I place the destination share in the dock for easy access by the end user.

Another note - the root share point is what mounts to 10.4, so if you have a Users directory, then Adam, then Work, the directory that will appear on the left side of the finder window and on the desktop is Users, not the Work directory.