5 replies to this topic

[Illrigger]

I just spent a long week on the phone with both Microsoft and Apple on this topic, and figured I'd save some people a lot of pain by posting this: Due to changes made in both products, Windows Server 2008 (RTM)'s new File Server Cluster role is incompatible with OS X 10.5, and 10.3 and earlier.

The details:

Apple, up until OS X 10.4, did not fully support SMB sharing, and could only map SMB shares by IP address. In 10.4, this was remedied and SMB shares could be mapped by NetBIOS/DNS name or IP. For some reason, in 10.5 they decided to remove this feature, and once again SMB shares can only be mapped by IP address (if you put in a name, it resolves the name to IP, and then tries to map with the IP). Under common circumstances, this does not present a problem and goes unnoticed, since DNS will route the IP address and connect, despite the lack of following the SMB standards.

However, in Windows Server 2008, Microsoft created a situation where this is not the case. With clustered file shares in Server 2003, a lookup of the shares on the cluster name or IP would show all shares both locally hosted on the node as well as those on the cluster. This led to situations where a user could map a share that is local to the node by the cluster name, but which would not be there if the cluster failed over to a different node. In order to remedy this, Microsoft created a new extension for the Server service called file share scoping. This segregates the shares owned by the cluster from those owned by the node. This issue is that they only got it working by name, not IP address. If you list the shares by the cluster resource IP address, you get ONLY the local node shares. This fails to follow the normal behavior of TCP/IP, where both the name and IP address of a resource will return the same values.

Add those two oddities together, and you have a complete mess. OS X 10.5 clients (the only ones you can buy now) are incompatible with Server 2008 if you install this role - they will not be able to mount any shares hosted by the cluster.

Note that Mac clients have no issues with 2008 normal file shares; this is ONLY when using the clustered file server role.

After speking extensively with both parties, they have both acknowledged the issues exist and that they both have standards issues that need to be resolved. Both have promised to have a fix in a future OS update, but state that the changes required are too extensive to be resolved in a hotfix, and will need to be addressed in a major update (a service pack-type time fraom from MS, and a point update (10.5.x) from Apple).

So , bottom line:

IF YOU HAVE MAC CLIENTS RUNNING ANY VERSION OF OS X OTHER THAN 10.4 (TIGER), DO NOT INSTALL THE CLUSTERED FILE SERVER ROLE IN WINDOWS SERVER 2008.

KEYWORDS: broken pipe sorry the operation could not be completed because an unexpected error occurred (error code -6602) mount_smbfs mount -t smbfs

[Phonics Monkey]

Sorry about chopping up your post, but I wanted to cut-out two statements that are bugging me.

Under common circumstances, this does not present a problem and goes unnoticed, since DNS will route the IP address and connect, despite the lack of following the SMB standards.

If they are starting with an IP address DNS will(/should) never come into play. Unless you're saying Apple is re-routing IP addresses back through DNS instead of just using them as an IP address like normal computers are supposed to.

If you list the shares by the cluster resource IP address, you get ONLY the local node shares. This fails to follow the normal behavior of TCP/IP, where both the name and IP address of a resource will return the same values.

The whole point of the Round Robin brand of load balancing is that any machine anywhere can target a single name, and get any one of X IP addresses back based on which target (IP) is closest to the requesting machine. The name request's "return" value is an IP. The IP's "return" value is an actual machine.

...Now I'll admit that clustering isn't my strong suite ... but unless a cluster can allow multiple machines to have the same IP without causing a collision, I'm not seeing a problem on Microsoft's side.

At any rate, thanks for the heads-up it should save some folks a good bit of anguish.

[Illrigger]

On the first quote, it does pass IP through if you mount by IP, but if you mount by name it resolves to IP and mounts by it. More technically, in 10.4 and linux, the system uses the name to resolve the IP, contacts the computer (or cluster resource in this case) by IP, uses that connection to gain the NetBIOS name of the resource/server, and then connects via NetBIOS name. This is the correct way to address an SMB share. In 10.5, the process stops after retieving the IP, leaving NetBIOS out of the process and causing the issue.

On the second quote, this is a failover cluster, not a network load balance or round-robin cluster. A failover cluster does indeed allow a single "machine" to have multiple IP addresses. It creates a virtual resource that has a static IP, DNS, and NetBIOS name independent of the physical servers, which allows it to move around among machines in the cluster. You then attach resources you want to move with it, in this case a disk array and the shares on it.

As for IP being the final answer, that's true, but the reverse is not necessarily so - which is why the process mentioned above uses NetBIOS to retrieve the computer's name. Reverse lookups (IP to name) are not required by NetBIOS, and by default a microsoft DNS server doesn't even create the reverse tables. However, in practice, if you look up a server by name or by IP (even if it has multiple names), you should see the same things - if it's a file server, like this, you should see the same list of shares when resolving by name or IP. This is NOT the case here - you're seeing DIFFERENT things when you look at the shares by name and by IP address. If you look by name, you see the shares on the virtual resource (the clustered shares), but if you look by IP, you see the shares on the physical server that's hosting the cluster resource. This breaks the logic that DNS is based on. Microsoft counted on NetBIOS in this case (justifiably, since SMB is reliant upon it), and even though they tested the current gen of OSes and found all of them working, 10.5 didn't ship until after 2008 went to RC, so it wasn't part of this process.

I agree that Apple is more at fault than MS in this case, as they took a feature that worked in 10.4, and for some reason broke it in 10.5; however, MS should have taken the time to allow for reverse DNS compatibility instead of relying strictly on NetBIOS. The engineer I worked with even admitted that it was a difficult process, and they chose not to pursue it further. After realizing the issue's implications with their largest competitor, they have decided to go back and fix it.

For now, I'm rolling the share volume out of the cluster, and will address it locally for the time being. I will probably wait for MS to fix their half so that older 10.3 clients which might be lurking around on campus don't have issues. I have egg on my face, but at least I have an answer - and a Mac in my office so I can do testing on more than 10.4 like I had access to before.

[Phonics Monkey]

Okay, I think I see where the break down is now. But what largest competitor are you referring to? Apple? Or Linux? Apple is no compitition for MS in the server market, and the NetBIOS/SMB snafu is their's alone...Yes?

The MS no reverse DNS zone by default annoy's the hell outa me, so I refuse to leave a server deployed that way.

A Mac in your office? (Zoiks!) ...It's in a corner where you can throw something over it, right?

[Illrigger]

I was speaking to the desktop market (where Apple is around 10% market share, Linux about 1%). The issue here is client connectivity; if MS were accused of purposely blocking new Macs from connecting to their servers, it would be an instant anti-trust suit.

I make sure to always create reverse zones as well - though thankfully I'm not in charge of that side anymore. Why MS decided to not do it by default still mystifies me.

As far as the Mac goes - it's a PowerMac G4 867MHz with 768MB of PC133 SDR RAM and a pair of 40GB 5400RPM IDE drives - pretty much the bare minimum to run leo. It was in the spare machines stack.

That being said, I'm going to get an iMac as my primary machine in the next cycle. I was thoroughly impressed with OS X during my troubleshooting, and with VMWare Fusion and BootCamp running Vista on it, it allows me to do everything I need to on the PC side while giving me more flexibility, and access to the surprisingly awesome Office 2008 - the new Entourage is really, really slick. I'll still keep my laptop a PC for betas and such, but I'm really looking forward to having a Mac on my desk (and this boat anchor G4 off of it!).

[jclyon3d]

Regarding OSX 10.5, we added the SMB port number 139 to the machine name and it works fine. From 10.4 you would need to edit the nsmb.conf file to prevent them from attempting to encrypt the credential password (I think this is whats happening), then it should work also. See http://support.apple.com/kb/TS1564?viewlocale=en_US for the edit value. From 10.6 all seemed to work right out of the box.

Edited by jclyon3d, 19 January 2010 - 09:26 PM.