Win2003 Server R2 and copying files to share using SMB 0KB in size

[cashxx]

Just wondering what others have found as a workaround for this issue? On MacWindows.com the subject is 0KB files when trying to copy to WIndows server or something along those lines.

I have been testing Leopard for a while now and haven’t had any issues and our Windows admins upgraded our 2003 SP1 server to R2 and latest updates and it seems to have broken my 10.5.x clients. Now when trying to copy files to a share it errors out and shows the file on the share but its 0KB.

Things work fine from Tiger and Windows XP clients so its not permissions…..seems to be a bug with the Leopard finder and 2003 server R2 release or one of the patches since SP 1.

About the only thing that seems to have helped a little was to simply check full control for the user on there folder and then set it back to Modify and things work fine. Still getting reports of students not being able to copy though so thats not 100% reliable. I have also found that for the Share Level Permissions if the users are set to Full Control it fixes the issue, but thats bad to do and leaves a hole open. This kinda feels like a bug I found with Tiger that got fixed in 10.4.6.

Just wondering what others are finding?

Thanks,

Dan

[cashxx]

This is going back a little ways with 10.5.x. But the issue still happens with 10.6.x and I think we found a fix! The quick fix was just to re-push the permissions on the users folder and it would fix the issue, but if you have hundreds of users its a pain and it would be nice to not have the issue at all!

When our users are created in bulk we do everything from the command line in Windows XP and now Vista. The admin has always used cacls to set the permissions, but found that using icacls that is new with Vista/Windows 2003 R2 I believe with different switches seems to fix the issue with 0KB file problems and errors when trying to copy files to a Windows 2003 R2 server in our case.

Today we found that when setting permissions using cacls it was missing the AI attribute or ACL or whatever, but when using icacls things seem to be fine and write the correct attributes:

Bad created with cacls \\server\share\userdir /e /t /g testmulti:c
User Account: Testmulti
D:(A;OICI;0x1301bf;;;S-1-5-21-510418058-1399010721-837300805-17731)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;DA)(A;OICIID;0x1301bf;;;S-1-5-21-510418058-1399010721-837300805-8532)(A;OICIID;FA;;;SY)

————————————–

Good created with icacls \\server\share\userdir /t /c /grant testmulti:(OI)(CI)M
User Account: Testmulti
D:AI(A;OICI;0x1301bf;;;S-1-5-21-510418058-1399010721-837300805-17731)(A;OICIID;FA;;;DA)(A;OICIID;0x1301bf;;;S-1-5-21-510418058-1399010721-837300805-8532)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)

We have finally found a fix we think by running the following commands to create a new user folder and set permissions for new students:
mkdir \\server\share\userdir
icacls \\server\share\userdir /t /c /grant testmulti:(OI)(CI)M

Still seems like a bug because when it started happening with Win Server 2003 R2, we setup a new test server and a fresh OS X client and doing permissions through the GUI we were able to reproduce the error. But it looks like using icacls will get us pass the issue hopefully now.

Thanks,

Dan Ball
PTI.EDU

[Author]

Posts