4 Replies Latest reply: Apr 10, 2008 4:55 AM by nmonkee
jonasmixter Level 1 Level 1
I have a problem when connecting to a SMB file share on a Windows 2003 R2 server (also acting as a Domain Controller for the Active Directory domain) using OS X 10.5.2.
I've just reinstalled Leopard to rule out any problems with messy configuration on the client, but the problem persists. The newly installed Leopard client is not a member of the AD domain at the moment.

When connecting to the server share (with cmd+K in Finder), I have to login using a AD account. The share is after successful login accessible through Finder and I could traverse the folders and read / copy all the files on the share. I could also save smaller files (less than 16 KB) to the server.
However, if I try to save a larger file (more than 16 KB) the files gets created on the server share, but stays a 0 KB. The access to the server share freezes during 60 seconds and the "Copy" window just tells me it has copied 0 KB of the file so far. No data seems to be written to the file at all.
After Finder gives up, the "Copy" windows tells me that "The operation cannot be completed because you do not have sufficient privileges for some of the items".

From time to time Finder has also disconnected the share during problems, and OS X has crashed on me in kernel panic four times when testing. I haven't been able to track down the action triggering these errors yet.

The shares on the server works just fine when using the same username/password from a Windows XP client machine.
I don't see this problem when mounting a share from a Windows XP client in Leopard.

What could be wrong here? Is there some setting on the Windows server that has to be done to work with Leopard? (I've read about the SMB signing, but Leopard shouldn't need the signing to be turned off, should it?)
At the moment I'm having a hard time using the shiny new MBP at work, so any help on this would be highly appreciated!

Best regards, Jonas Mixter

MacBook Pro, Mac OS X (10.5.2)
  • jonasmixter Level 1 Level 1
    Hi all!
    I found the solution later on myself. I'll post some links here if someone else needs help and got the same problem.

    It seems like SMB packet signing still need to be turned off, even though Leopard should support SMB signing according to the list of 300+ new features (http://www.apple.com/macosx/features/300.html).

    SMB packet signing enables encryption and is enforced for all connections by the server if the server is running Windows Server 2003 R2. (As in my case...) Before 2003 R2 SMB packet signing is used by the server if the client supports is.
    More information about integrating Leopard with AD could be found here: http://www.smallbizserver.net/Articles/tabid/266/articleType/ArticleView/Article ID/234/PageID/357/Default.aspx and linked from that site is this information about disabling SMB packet signing (http://simultaneouspancakes.com/Lessons/2004/12/27/how-to-disable-smb-signing-in -sbs-2003/)

    Best regards, Jonas Mixter
  • Steve Copley Level 1 Level 1
    Thank you *so much* for that information - I was going nuts trying to move files over to my Windows 2003 file server just after I promoted it to an AD domain controller.

  • nmonkee Level 1 Level 1
    I have an issue with OSX Leopard (10.5.2) , where by I can't write to NTFS shares on W2K3 servers with SMB signing turned on and IPV6 disabled for the interface.

    To recreate the issue:

    Create a folder named test that contains two files one named ._test.txt and test.txt on OSX and copy to an SMB share on W2k3.

    This results in spurious errors about permissions and locked files.

    Copying a file larger than 4k results in the error:

    "The operation cannot be completed because you do not have sufficient privileges or some of the items."

    Using mount_smbfs from a shell on OSX results in the error: "Permission denied"

    host:~ user$ mount_smbfs //user@server/share /Volumes/test-smbmount/
    host:~ user$ cp test.docx /Volumes/test-smbmount/
    cp: /Volumes/test-smbmount/test.docx: Permission denied

    Using smbclient from a shell on OSX results in SUCCESS!!!

    host:~ user$ smbclient \\\\server\\\share -U user
    Domain=DOMAIN OS=Windows Server 2003 3790 Service Pack 2 Server=http://Windows Server 2003 5.2
    smb: \> put test.docx
    putting file test.docx as \test.docx (784.7 kb/s) (average 784.7 kb/s)
    smb: \>

    There is an alternative solution if you do need to drag and drop in your gui world, it'll cost you $120

    link: http://www.thursby.com/products/dave-eval.html

    I have mailed the developer as he has obviously identified the root problem of the issue and I urged him to share his patch/resolution with Apple in the interests of the user community and a darn nice thing to do.I had a response form the developer to my request. I sent my workaround solution to the developer and stated that in my opinion the pricing for the software seems unnecessarily high based on the functionality it provides and way above what I would be willing to pay to resolve one small issue.

    <developers response>

    Pricing is a difficult topic to discuss -- but if you have no use for the product, any price is too much. As for reporting bugs to Apple, they'll listen to customers much sooner than they'll listen to developers. And they have some of the brightest engineers I know. If you report the bug to them, they'll likely have it fixed in the next update.

    </developers response>

    I couldn't find away to report the bug myself so I had a friend do it for me. The response I had back from Apple was less than satisfactory.

    They believe that the issue is to do with NTFS streams and that a file containing ".com.apple.smb.streams.on" needs to be created and placed into the root of shared volumes. This is not a fix!

    If you want to prevent writing the "Apple Double" files to a remote share, enter the following into a terminal:

    $ defaults write com.apple.desktopservices DSDontWriteNetworkStores true

    Problem still exists.

    ref: http://docs.info.apple.com/article.html?artnum=301711

    <apple double description>

    ref: fhttp://docs.info.apple.com/article.html?artnum=106510

    Before Mac OS X, the Mac OS used 'forked' files, which have two components: a data fork and a resource fork. The Mac OS Standard (HFS) and Mac OS Extended (HFS Plus) disk formats support forked files. When you move these types of files to other disk formats, the resource fork can be lost.

    With Mac OS X, there is a mechanism called "Apple Double" that allows the system to work with disk formats that do not have a forked file feature, such as remote NFS, SMB, WebDAV directories, or local UFS volumes. Apple Double does this by converting the file into two separate files. The first new file keeps the original name and contains the data fork of the original file. The second new file has the name of the original file prefixed by a "._ " and contains the resource fork of the original file. If you see both files, the ._ file can be safely ignored. Sometimes when deleting a file, the ._ component will not be deleted. If this occurs you can safely delete the ._ file.

    </apple double description>

    I am not the only one this issue. A quick peruse on http://macwindows.com/ will show that numerous people are suffering and numerous workarounds have been suggested. Sadly none of which work for me. Each work around is stranger than the previous. Such as disabling IPV6 and updating Daylight Savings Time.

    The issue lies with the samba integration. I am primarily a Gentoo Linux user and this kind of bug would have been resolved almost instantly if present in open source software.
  • nmonkee Level 1 Level 1
    Ok so more and more in depth googling has shown that tons of people are experiencing the same issue. The 'fixes' and workarounds that people have suggested, tried and in some cases had some success with baffle.

    * turn off IPv6
    * enable SMB file sharing and assign READ/WRITE for EVERYONE
    * re-install Leopard
    * delete all credentials in the Key Chain
    * add and remove the machine from the domain
    * delete and re-create network service profiles
    * delete and re-create shared folders on the server
    * change computer name, NetBIOS name, DNS entries
    * the list goes on and on...

    The only way I can find that will allow OSX Leopard 10.5.2 clients to mount, read and write to remote SMB shares on W2K3 servers is.....

    Turn off SMB signing. Apple have borked their implementation.

    From: http://www.apple.com/macosx/features/300.html

    Windows SMB Packet Signing
    Enjoy improved compatibility and security with Windows-based servers.

    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

    now OSX Leopard 10.5.2 clients can mount, read and write to remote SMB shares on W2K3 servers.

    ** Good luck convincing your domain admins to downgrade their enterpise security for OSX users. **