Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Other testing -

I removed all other users from both the share, and the underlying windows folder (NTFS). I also made sure that my account had full control both the share and underlying directory...

That means that my user account was the only one to get access to the account, which it can, and delete files - just not add them.
 
Of course, I'm having much more luck storing stuff on my new Mac Pro...

I can add and delete files from my macs and pc's there - so maybe the bell will toll for my windows storage server.
 
Another update - It also appears you can copy some files - just tiny ones (<20k) and the copy works...

Since some files work but not all, I'll agree this is definitely a bug in Apple or Microsoft's implementation of SMB
 
Another update - It also appears you can copy some files - just tiny ones (<20k) and the copy works...

Since some files work but not all, I'll agree this is definitely a bug in Apple or Microsoft's implementation of SMB

Same here- I just tested it- I was able to add a 4 kb text file to the server and delete it, but no luck with anything bigger.
 
Hmm.. that's an odd problem. Are you both trying to write to Server 2008?

BTW, good job with the troubleshooting!
 
Hmm.. that's an odd problem. Are you both trying to write to Server 2008?

BTW, good job with the troubleshooting!

I can't be sure- I think I saw a Server 2008 box on my IT guy's desk. Again, I have to do this without any support from my IT- the other guy in the office who uses a Mac was told to use RDC while in the office to access the files!! I don't even think that there was an attempt to make a direct connection. Is there any way to tell on my end? I tried viewing properties on my windows pc on the server shares but that doesn't give any info.
 
Well, when your friend connects to the server using RDC, it should say what the server is running at the login prompt that comes up in the RDC window.
 
Here is the fix.

This is how I fixed the issue. 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)

Good luck amd let me know if this works for you.

Aaron Onidi
 
I just tested from 2 leopard boxes to 3 different 2003 servers and had no troubles with writing files. I tried file sizes from 24k to 248k with both SMB and CIFS connections. I should note that I do not directly support the server backend, that is handled by another team. But they are a Windows only group and not keen on making any schema changes to make Mac user's lives easier. So.. if the changes that aonidi noted above are changes from the default behavior.. maybe?
 
I found the solution

Thanks Aaron for your fix, it worked for me. My server is running Windows SBS 2003.
 
Can someone please explain to a non-technical person where to do the stuff that Aaron suggested? Is that to be done on the Windows server or on the Mac?
 
Our IT guy won't make those changes on the server. Wondering if there are any other solutions.

I too was able to copy a small file, once I tried a large one I got the same error as mentioned above.
 
Our IT guy won't make those changes on the server. Wondering if there are any other solutions.

I too was able to copy a small file, once I tried a large one I got the same error as mentioned above.

I'm in the same boat. Is this an Apple bug so that we could at least hope that the next leopard patch would fix it?
 
FYI -

It's been a while since I looked at this - I've just been avoiding copying files to my server...

But I tried the Local Security Policy changes above and they worked. In WS2008, the UI is disabled for these changes (at least on a ad domain controller) and you need to edit the registry. The UI points to this support article:

http://support.microsoft.com/kb/823659
 
Our IT guy won't make those changes on the server. Wondering if there are any other solutions.

It looks like this policy is enabled by default in WS2003 SP1 and WS2008.

One note - the KB article suggest times when it is wise to disable this security policy:

"Risky configuration
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting in domains where not all domain controllers can sign or encrypt secure channel data is a risky configuration."

I'd check with your domain admin - do your servers use a trusted Certificate Authority? My guess is that people who don't have this issue have domain controllers using certificates from trusted CAs while those of us who had a problem with this issue are working with some local CA.

I'd at least send this KB article to your admin and have him/her take a look.

http://support.microsoft.com/kb/823659
 
Is this it?

Is this just "the ropes" without 3rd party software. ADmitmac is software that

... supporting both Intel and Power PC Macintosh computers, allows users running Mac OS X 10.4 Tiger or Mac OS X 10.5 Leopard to participate in Microsoft networks taking advantage of all the directory services provided by Active Directory, NT, and Apple’s Workgroup Manager.

It even says in the second paragraph:

It supports the highest level of security and does not require the downgrading of security when using Windows Server 2003.

Is that it? Either you decrease the security as mentioned above (presumably by doing the steps laid out by aonidi), buy 3rd party software, or no full network access?
 
smbclient workaround

So I have an issue with OSX, 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/
Password:
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
Password:
Domain=[DOMAIN] OS=[Windows Server 2003 3790 Service Pack 2] Server=[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.
 
OSX Leopard (10.5.2) can't write to windows smb share

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/
Password:
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
Password:
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.
 
Fixed in our environment

Hello,

We fixed this problem in our environment by giving our mac users explicit, not inherited from groups, modify rights to the directories in our servers that they needed access to. This is something your domain administrator would have to do.

For those of you who are domain admins, you will need to go into your server share, right click the folder they need access to, security tab, and add the mac user and check "Modify".
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.