http://support.apple.com/kb/HT3229
These permissions allow a drop box to work, however, large files being transferred from a Mac client show up while transferring, then disappear. Copying to other folders is fine. Copying from another folder that is shared into the drop box works. Does anyone else have a reliable drop box configuration for Windows Server 2003 for Mac OS X clients? We are not using the Macintosh file services anymore and wish to use standard Windows/SMB sharing.
Edit The files range from 1 meg to 2 gigs. Its NTFS. Its our file server.
Edit 2 A drop box is like a mail slot - things go in, but things don't come out. Essentially, it is a write, not a read or list directory contents.
In addition to the kb article you mentioned, I would suggest checking out ExtremeZ-IP (http://www.grouplogic.com/products/extremeZ-IP/), a program which will install on your 2k3 server in order to help facilitate the transfers. I used it in a mixed-OS environment where large graphic files were transferred between the server and Mac clients routinely. It definitely helps speed up the transfer and I never ran into any issues with large files disappearing after it was configured.
From the Mac clients use only SMB://, there is no need for any other protocol. I use a MacBook all the time and never had a problem with Windows shares. I simply connect to the share with an SMB:// connection, just as I would if I was using a Windows client, and do what I need. Files copy just fine in either direction.
As for the file system, other than system imposed limits (e.g. file size) it makes absolutely no difference whether it's FAT or NTFS. That aspect is handled by the host, not the client. Using NTFS on Macs is only an issue if it's on the Mac itself, such as an NTFS formatted external drive.
Native Windows will allow file shares that Mac users can use.
That being said, without something like ExtremeZIP, your Resource Forks will be as useful as udders on a bull. If you have no need for resource forks, no problem, Macs connect to web servers, ftp servers, etc. on Windows all the time. But I'd hazard a guess that there have been times that files didn't come down as expected, or were entirely worthless as said udders to users who didn't know that the type and creator codes were what tells the file to open in a given program. Stuffing your files grants more protection than just shrinking the size of the download. Graphic artists, designers, photogs and musicians, can be really cross if they loose things like all the IPTC info.
Another thing to Note - if are in a Mixed OS netork environment - either all Macs connect via afp, or they connect via smb, but they don't get to pick and choose unless you give them a bogus number to the help desk.
We recently migrated from one server (running ExtremeZIP-a great software package for Macs on Windows) to another server (running FullPress, using k-share)
We'd offered to move the files (mondo Gigs worth of files) over a weekend using an Applescript - told them the benefits - files would retain date and time info, resource forks, etc.
"No, no, no, NO!" said the managers, "We want to organize things during the migration." So we set up a meeting to discuss how they would do this task. Needless to say, time after time, they blew off the meeting. So eventually, the managers assigned the artists (each of whom have a PC and a Mac,) to move the newly "organized" files.
The artists didn't want to "give up" the use of their Mac, so they figured they would use their crummy old PC to mount shares from the 2 Windows Servers and transfered gigs of in-production files on the PC by dragging them from one share to the other.
We found that they'd moved the files when the Help Desk became innundated with an avalanche of calls - "folders look like packages," "my graffle files imploded," " I can't see the file on one Mac but my partner can from another,"
Permissions were completely hosed, deadlines were blown, clients enraged and Art Directors armed with matte knives were lurking in the parking lot looking for the Systems Admins. I still shy away from users wearing blue jeans and Birkenstocks in the elevators ...
Desparate to figure out what happened, I hazarded a guess and made 2 connections to the same share, one via afp and one via smb and discovered the source of the catastrophe (those wicked, wicked artists!)
You MUST have a Mac in the Middle when transferring files from one Windows server running a Mac to another to retain the resource forks.
Just a word to the wise, never let a bunch of overly caffinated, unsupervised, sugar-amped users, listening to Slipknot at Midnight, move their in-production files ... unless you make them sign a disclaimer, first.
The weight of the file is an issue only for the timing it implies, lighter files will give the observer no time to see the "temporary file" during the transfer.
My guess is that w2k is applying the umask only after the transfer is completed, this sounds strange but is the only reasonable cause I can see. The strangeness is mainly in the fact that it should be the dropbox folder to be write and execute/access only, no content into it should never be shown...
We ended up using cfis as the protocol name on the Mac.
Mac's don't like NTFS. There is a program for Mac's that allows them to see NTFS, but I can't think of its name. I am sure a google search would come up with something. SMB works for us with FAT32 shares on a Windows 2003 server.