Slashdot Mirror
File Sharing Difficulties Frustrate Tiger Admins
rmallico wrote in to mention a story currently running on Eweek about technical difficulties sites running Tiger are experiencing. From the article: "A number of sites running Apple's new 'Tiger' operating system are experiencing problems with SMB file sharing and authentication with Microsoft's Active Directory, Ziff Davis Internet News has learned. Although Apple Computer Inc.'s Tiger increases support for Server Message Block file sharing and Active Directory, several sources say that the Finder fails to log on to Windows and Linux Samba file servers."
The most interesting thing I noticed in the article was actually that the error message for the Connect to Server failure is "error code -36". A friend of mine who uses Mac OS X has always complained much about how the Mac never tells you anything about what is actually wrong, only gives you a number that is in no way useful for solving the problem. It is amazing this is still the case in Tiger, what in the world would be wrong with giving at least a tiny bit of information or just a hint of what is wrong? Even the good old Windows blue screen is more informative than "error code 4".
9/11: Never forget it was a false-flag operation
Whatever the issue is, my guess is Apple will have it fixed within the month. It's possible they will have a patch out by the end of next week. It's just a bug, and last time I heard, unless active measures need to be taken by network admins NOW to shore up potential security issues, bugs aren't news. Major new OS versions will always have wrinkles to iron out, stop the presses!
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Easy workaround:
Command-K to bring up the connect menu and type in the full address INCLUDING THE SHARE NAME:
smb://SERVER/folder
I've said it before, and I guess I'll have to say it once again -- zealotry should have no place on slashdot. If Microsoft turned around and released a perfect, bug free operating system that interfaced perfectly with all the competitions' offerings, there would be a 1000 comment shitstorm of complaint as the flock of rabid posters decried them for not releasing the source, or for charging for the software. Compare that to this, where a major operating system has been released with a large and quite frankly obvious bug present, and along come the apple fanboys. GET OVER IT. Base your opinion on the product, not the company, or the shiny form factor, or the how overpriced it is.
Don't get me wrong, as I sit here I am listening to a 40 gig iPOS, and I use a powerbook when I need mobility, so I don't have any bias against apple themselves, just their little army of braindead followers who would buy and defend a box of Steve Jobs' shit if it had a pretty shape and the apple logo.
Hah, and it seems after previewing the parent comment is already rated insightful. Funny how that works, isn't it?
Making the moon less necessary since 1998.
Weird, I've found with Tiger that Windows file sharing has been easier, although I don't use Active Directory. With Panther my password was never remembered by Keychain, despite clicking the option to enable it. With Tiger my password is remembered. It also finds my Windows shares automatically, whereas with Panther I had to manually connect by entering IP addresses.
One friend indicated that things refused to work in plaintext-password mode, but once he turned on encrypted passwords, they worked fine.
I'm not sure whether he had to turn on the encrypted passwords at the Mac end or the PC end, but I seem to recall thinking "gosh, imagine that, doing something the secure way."
Village idiot in some extremely smart villages.
I got this solution from here by the way. Thanks to Drew McLelland.
Why would anyone want to use a text editor that is not vi?
I find this interesting, because at the university where I work, the security policy requires centralized AD authentication from all computers in the network. After that I've hardly seen any Linux PCs or Macs around anymore. When I asked about it from one of our IT guys, he said that you can't authenticate non-Windows computers with MS Active Directory.
The owls are not what they seem
I had this problem too after upgrading. I found that deleting my SMB keychain entries solved it allowed me to login again (after getting my admin to unlock my account from all those failed attempts).
The admin's wrong. Samba can do it now, although in all fairness it took a while after active directory was released for it to be able to work with it well. He's probably just basing that on old information.
As far as the protocol, SMB is (IIRC, I could be wrong) an IBM-designed protocol. It's been around for ages - hell, NT domains were just hopped up lan manager networks. The authentication in active directory uses a slightly modified form of kerberos - also an open protocol. They have tried to put a few legal barriers in the way, but those have been mostly ineffective.
Now, there is another possibility - it might be against policy at your university for non-windows machines to authenticate. If it's set up so that all machines have to be added to the tree by an admin, it's certainly enforcable, and thus your admin would be right in that particular case. He's just not right in the general case.
Those who can't do, teach. Those who can't teach either, do tech support.
hi. AD is just LDAP with some extra cruft/bloat/stuff added; which is mostly documented anyway. Your IT department is clueless. You can also fall back to kerberos (which despite the FUD, interoperates with the majority of MIT Kerberos V implementations), if you did not have a functional (Open)LDAP infrastructure.
On a related note: I'm seeing really bad performance when copying a file from a Linux Samba share to my OSX machine (roughly 100 kb/sec, if that). Oddly enough, file uploads are ok (megabytes per second). Odder still, if I open a terminal and copy directly to my machine from the Samba share mount point, incoming copies are fast too. This has been going on from at least 10.2, and much to my dismay it is still an issue in 10.4. This really seems like the Finder is trying to talk Sambalese by itself (and does so differently than the SMB filesystem driver). Has anyone else noticed this behavior (and, perhaps, solved it)?
I used to work with samba, having a linux fileserver and a mac osx powerbook, but recently I started working with nfs. It seems a bit faster and more stable. When I change some file on the server, it's directly visible in finder - without having to refresh it.
I also was annoyed the fact when I turned my powerbook on after it went to sleep it would give me a lot of errors about unmounting a network drive. This also was the case with tiger. With nfs, those problems are gone an nfs mount will stay active after the powerbook comes back from sleep.
I first started using OS X in the early days of 10.2 (yes, a relative latecomer). This was when my wife bought an iBook (after some *ahem* guidance... read encouragement) for studies she was undertaking. When she wasn't working on it, I got to play and set to work integrating it with our home network.
The pain I had getting SMB to perform acceptably under 10.2 nearly put me off OS X. Basically, the way that 10.2 handled mounting network filesystems really sucked. It was unreliable and often left the system hanging with a spinning beachball (the Mac equivalent of an egg timer). Often, powering off was the only solution.
This was fortunately fixed later on in the 10.2 lifecycle with some networking updates. Things got much better from then on.
When I got my own iBook several months later, it arrived with 10.3. This release seemed to have a reasonably good SMB implementation, but the performance was truly sucky. File transfer speeds between the iBooks and my Linux-based Samba server were low, but at least mounting was reliable.
As 10.3 progressed, this problem went away and performance/reliability are currently both very good. It means I can use SMB between my Linux server and both iBook and Windows XP clients. All works just fine.
I am, however, considering a move to WebDAV for file sharing on the network. WebDAV is a nicely lightweight protocol and has the benefit of being an open standard. Most good implementations are open source too. There are also client libraries for most decent scripting/programming languages. The added benefit is that you can integrate the WebDAV server in to OS X to perform iSync backups of your system and do calendar sharing etc. All nice, geeky, stuff.
The only major problem I can see at the moment is that the way the WebDAV server interacts with the underlying filesystem is a bit complex, given that my server runs under Apache. The model it appears to assume is that the server will have a dedicated directory or area for WebDAV files, and not simply share out a user's home directory or a backup drive.
I do need to go and RTFM, however.
Contribute to the online videogame encyclopedia: GamerWiki
These kinds of things are the normal evolution of Mac OS X after each major release. Get new features and added speed as an initial tradeoff for lower stability and reliability. Anyone who has used the Mac OS since the early days of OS X should know this.
I'm sorry, but if you are installing Tiger onto a mission-critical system, you deserve the problems you get. Give the software time to mature before rushing to employ it in your networks.
8==8 Bones 8==8
Perhaps they need to do more automatic regression testing (daily) on each build then?
I think the car analogy is (for once : ) a good one. We have come to expect failure from Software, and that shouldn't be the case - it should be very rare, not inevitable with each new release. They did rush the release of Tiger, and certain things suffered for it. Yes they will probably fix it quickly, but it'd be nice if they had a more extensive testing program, with sufficient time alllotted to do the QA work, for catching regressions like this.
Is it too much to ask that vendors use beta versions of their own software in-house for a month before they release it? Is it too much to ask that they ship the software to a small number of beta testers before the final release in order to find those wrinkles and iron them out?
This is a common complaint heard about all kinds of products from cars to drugs. What it reflects is ignorance of the statistics of testing. By necessity, testing must be done on a pool of people that is orders of magnitude smaller than the final pool of users (a test on everybody is not a test, it is a product roll-out ). So let us say that you beta test on 1,000 people and roll the product out to a million. Then you will have about a 35% chance of missing a problem that affects 1 person in 1,000. On roll-out, each such problem translates into 1,000 people with problems.
If an "admin" installs a brand spanking new OS immediately after release, that admin should have his pocket protector taken away from him. Particularly if one is working in a business or other mission critical environment, installing new OS without giving time for new bugs to be discovered and addressed is a sure sign incompetance.
Hey, I like Macs. I think Apple rules the roost in the OS world, etc. But hey, reality check:
.0 release and expect that it would not be without bugs? I say if any sysadmins out there were silly enough to make a hasty upgrade before testing (ignoring the above caveats) they deserve the problems they're experiencing.
SysAdmin Rule #1: If you depend on it, and it works fine the way it is, don't mess with it. [If it ain't broke...]
SysAdmin Rule #2: If you want to mess with it, test it before deploying it.
Why the hell did people install a
We waited to deploy WinXP until the first service pack was released--and that saved our ass. I think it's ignorant to ignore that principle on the Mac side as well--esp. with a major update.
Early adopters are unpaid beta testers. Congratulations--you found the bugs!
I might know what I'm talkin' about, but then again, this is Slashdot...
...you're a fool and deserve everything you get if you put a week-old OS on production hardware without doing non-production testing or having a fall-back.
.2 or .3 service releases have been out for a few weeks. A couple of my clients used to question this conservative method until some renegade users bought and installed Panther right after its release (without authorization from anyone) and ended up being basically unable to work until I reverted them to the standard OS/applications build.
.4, and even then we clone the old drive to a FireWire drive before upgrading, just to be safe.
If you insist, however, do it right. Prep a build of the new OS and put it on its own hard drive in the machine of your one or two most clueful end users. Let them beat on it for a while and document their problems/questions as they try to do their work. Once in a while go through the list and address their fixable issues. If they happen upon a show-stopper, they simply boot from the drive with the old build on it and use that until the next service release appears. Then you apply it, and test again. Repeat as necessary until the number of issues is low enough that you can confidently deploy the new OS build to all end users.
I have used this technique to great effect at several of my Mac clients, though I don't even consider giving them the newest OS until the
As for OS X Server, that gets tested in my company's lab and on my bench at home from the day we get it, but it doesn't get rolled out anywhere until
~Philly
99.9% of admins who know how to do their jobs correctly didn't go out and buy Tiger the first day, but chose to wait until a few bugs were worked out and the OS was generally seen as in good condition for mass-use. 99.9% of admins are casually going about their job instead of frantically trying to fix a problem that didn't need to be created in the first place.
That's odd.
I'm running into the exact opposite scenario:
Under Tiger, SMB filesharing *screams* as compared to how it ran under Panther and earlier incarnations of OS X. I'm able to connect to my samba fileshare on my Linux box, and my Win XP box, without any trouble whatsoever.
In the past, I was always able to connect, but file transfers were dog-slow. They seem normal now.
Go figure.
Actually, it's not just the foreground app. The wait cursor indicates that whatever app that owns the window currently under the mouse cursor has had pending, unprocessed events for over three seconds.
You can still switch to another application. Swinging the cursor over a window of a background app that was unresponsive will give you quick feedback in the form of the wait cursor if that app is still unresponsive.
The other day a colleague of mine installed Tiger on his laptop (he never had it bound before, just connected to whatever shares with Cmd-K, etc.). He asked about using his AD credentials to log on. I told him "Sure, we just need to bind it to AD, do a few tweaks and anyone with an AD account could log in, just like Windows." Meanwhile, I was mentally crossing my fingers that there wouldn't be any new tweaks that needed to be learned.
So I pointed him to Utilities/Directory Access and had him click the Active Directory option, put in his domain (this is where I would usually start my VooDoo dances with the "advanced" options -- but I thought, "what the hell, lets give it a shot") click on Bind. It asked for a domain admin account, which I entered, and it bound without a hitch (I about fainted). I had him reboot (just to make sure) and then had him log in with his AD account. I worked beautifully, including mounting his home directory off our Win2K server. This had NEVER worked without tweaking for us under panther (although with a little tweaking under 10.2.8+ it worked fine). We transfered files, which went smoothly and quickly, and we looked around the network a bit.
Although I haven't thoroughly tested it yet, I'd say my initial experience with Tiger and SMB/AD has been great. That being said, MOST of our problems with Macs using our AD domain has been Windows-related (missing DNS entries, Sites-and-Services borked, or WINS not working/configured right, etc). Hearing about problems like this after a major change doesn't exactly surprise me, and I'm willing to cut Apple a bit of slack here. They are dealing with a reverse-engeneered protocol on networks where it is very likely that AD isn't in pristine or "best-practices" condition.
We have 35 sites using AD right now in our domain, and the migration from NT4 to Win2K/AD was a learning experience, to say the least. We've learned a lot in the process and, we've found that if you mess up something in AD in the beginning, it's damn near impossible to cleanly remove or fix it. I suspect that there are a lot of installations out there that still have AD ghosts hanging around that make 3rd-party integration a crap-shoot at best. What apple needs to work on is improving their tolerance for broken AD implementations, like windows does.
Of course, if MS would publish the full SMB/AD protocol it would be easier.
"terrorism" and "pedophilia" are the root passwords to the Constitution
What does the Media Access Control address have to do with this?
(Macintosh is abbreviated Mac, not MAC.)
There are two problems:
1) you have no idea how much testing Sarge has actually undergone. For all we know only 5% of users are using Debian/Sarge on a regular basis. While in theory any package in Sarge should have gone through two weeks of Sid testing first, there have been bugs in Sarge packages.
2) Sarge may be the best release ever, but have you tested it in your environment? Is the new version of an application going to be able to import your existing data?
Regardless of the quality of the software a new release must always be tested first.