File Sharing on Windows Server to Mac OS X clients

Question

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.

Solution 1

We ended up using cfis as the protocol name on the Mac.

Solution 2

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.

Solution 3

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.

Solution 4

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.

View more solutions

Comments

[Kevin Kuphal]

How large are the files? What filesystem type (NTFS or FAT) are you sharing from on the Windows 2003 side? FAT has a 2GB limit on file sizes.

[Chealion]

Are files always disappearing when the copy is done? And is it only as long as the files are larger than 1MB?

[Dmitry Lomov]

No, it varies depending.

[Kevin Kuphal]

FAT, FAT32, or NTFS shouldn't matter to the Mac via the share other than limitations the filesystem provides (number of files, sizes, etc)

[thaKAT007]

tuaw.com/2007/11/19/ntfs-on-your-mac-two-ways Good little article describing how Mac's play with NTFS. Link to pay software to fix the problem, but I have seen some free stuff. Google it and you will surely come up with something.

[Chealion]

@thaKAT007 - That's only for direct access to an NTFS drive (as in directly plugged in). A share means that so long as the server can read/write to it you're fine. (Obviously some file system limitations eg. 4GB file size on FAT32 are always there)

[thaKAT007]

Your going to down rep me? Wow, just wow! Have you ever done SMB to a Windows share from a Mac? I have and I can tell you from experience that anything NTFS (network shares, usb hard drives, etc) does not play well with OS X. I would down rep you if I could. Thanks for being my first down rep douche!

[thaKAT007]

@Chealion - Read the article I posted. You only have read access to NTFS shares in OS X.

[Chealion]

The question is about a Windows Server share and issues with a Mac client. And you have read/write access to NTFS shares on OS X (if your login permits you).

[Chealion]

To clarify: Shares from another computer (eg. Server). Not partitions.

[Dmitry Lomov]

This is a problem with a drop box permissions, do you have any on hand?

[John Gardeniers]

Sorry Daniel, I don't understand the question. I'm just guessing here but by "drop box" do you mean the Windows shared folder? For any kind of sharing with any operating system you need to ensure there are appropriate permissions for the account that will be used to access that shared resource.

[Chealion]

A downvote is not purposely downrep. "This answer is not helpful" is the alt tag. Enough meta from me.

[duffbeer703]

NTFS is not a network file system, and Macs work just fine with CIFS.

[Dmitry Lomov]

We are ridding ourselves of AFP.

[Jeremy Viet]

I tried that as well and took huge performance hits when copying multiple, larger files at the same time. If you're set on doing away with AFP, make sure to change the net.inet.tcp.delayed_ack setting by running this from the terminal: sysctl -w net.inet.tcp.delayed_ack=0 This will help overcome the "stretch ACK bug" that OS X inherited from BSD.