Carbon Core Training - Books

General Category => Mavericks Server - Foundation Services => Topic started by: urban420 on April 12, 2014, 07:23:06 PM

Title: File Share Error
Post by: urban420 on April 12, 2014, 07:23:06 PM
I'm finally getting around to deploying our new equipment and pretty much have everything in place. As I have said before, this book was a great help to me and I don't think i could have set up our server without it. Even though it does not cover everything you need to know, it does as it title states - it covers the foundation of things. At least as far as I am concerned there simply is no book/guide out there that explains things in a way that nearly anyone can understand in a way that this book does. To anyone looking for help with a OS X Server set up - get this book.

With that out of the way, I wanted to see if others are experiencing an issue that I have come across. I've been reads some threads at Apple and elsewhere and it looks like I am not the only one. In fact, it looks like it could be a bug with recent updates.

As I said, I am rolling our equipment out and we are pretty much all Apple equipment with the exception of a couple PC's. With that said when I set up file shares I chose to allow AFP and SMB protocols. So the problem I am seeing is when a file or files are copied to a share on the server an error is presented that states:

"The Finder can’t complete the operation because some data in “filename” can’t be read or written.(Error code -36)"

I have been working on our set up for a couple months and when I tested the file sharing previously I did not see this, so I suspect it is from a recent upgrade and it seems that others are saying the same thing. I found a couple threads on the Apple Support Site that discussed the issue so I chatted with Apple and apparently the issue is known, the fix has been developed and it will be forthcoming sometime soon.

Here are a of the couple threads:

I am just wondering if any of you guys have experienced the issue and what, if any workarounds you are using.

I also wanted to get your thoughts on the overall state of what I call the whole SMB Mess. I've read a lot about it and read why Apple says they had to move to a different, seemingly more proprietary SMB protocol, but they have had since Lion to get it together and it just seems it is still a mess. I guess I never saw these issues because I have always worked in a Windows driven environment and the Apple computers we had played well with MS Servers and AD.  But now that I have transitioned us to a Apple server I am seeing more and more of these issues. That is not to say Windows does not have their own issues, they just don't seem to be revolving around a pretty important thing like file sharing. But also the hardware manufacturers have not had a couple of years to get their stuff fully compatible and for whatever reason it is not happening.

For example this week I was moving our Canon multifunction copier to our new Apple network and I quickly found out that the Canon would not talk to the OS X Server. We scan documents to a network drive and I ended up having to use FTP, which is less than desirable. It is my understanding this goes back to when Apple made changes in Lion regarding the type of SMB. Our Canon is a few years old, so I went looking for a new machine thinking it would not be an issue with new hardware, but I found that very few multifunction devices will work well in a network environment with OS X. To be clear, I am talking about a small/medium business level multifunction unit and not a consumer grade machine, for example our canon is an ImageRunner. I am not sure how the larger business type models are set up but I think they have far more options and utilize internal HDD.

As I mentioned above we have to keep a couple of PC's around for our shipping department and I continue to run into issues there as well. Getting a Win7 PC to play well with OD has been a nightmare. In fact, I have all but given up on trying to bind it to the OD and simple things like connecting to shares on the OS X Server from the PC is a pain. It works, it just does not seem to be anywhere near seamless.

Sorry for the lengthy post, I just needed to vent. At this point I am more than a little displeased with the level of integration between all of the various pieces of hardware. It just seems like in the year 2014 we should not be dealing with these types of issues and it really should to be a bit easier.
Title: Re: File Share Error
Post by: Reid Bundonis on April 12, 2014, 08:35:30 PM
I will state that I feel your pain.  SMB in Mavericks (server and client) is a train wreck that took out a bus, fell into a lake, leaked hazardous chemicals, and then exploded, spraying its chaos everywhere.  Here is a snippet from the File Sharing chapter of book 2.

"At this time, SMB performance on Mavericks is abysmal.  AFP beats it everyday and twice on Sunday.  While Apple is trending toward SMB as the official network protocol on the platform, the time simply is not now.  Use AFP."

Now, this is a real sad turn of events.  Especially after 10.8.x was such a godsend in the Enterprise.  Finally, an Apple OS that could connect to SMB, DFS, and clustered file servers with NO 3RD PARTY SOFTWARE.  Ahh, I felt as though I reach the promised land.  And then 10.9 comes along and completely destroys all the advances made with Mountain Lion.

I now have customers in which I forbid them from buying Mac Pro and Mac Book Pros simply to ensure that they do not go onto Mavericks.

I've gone as far as building a Windows 2008r2 Server in my lab (yes, ouch).  I then took the Windows server and connected it to a 1000Base switch.  Into the switch I connected a Mac mini Server and a single Mac mini Client (iMac 27").  So this was a network of 3 devices.  No way for network congestion here.

On the Macs, I tested versions 10.9.0 through 10.9.2 (and just about each seed release) and no matter what I did (and I tried a bunch), the SMB performance was half that, or worse, of AFP.  I use the general rule of thumb that I should be able to push 4 GB/min on a good 1000Base network.  So I used a 500 MB file and expected a performance range of 7 to 10 seconds to push a single 500 MB file.  When the SMB tests took over a minute, I started to panic.

I tried making sysctl adjustments, I tried changing the MTU of the interface, I tried altering the Windows Chimney values (found some suggestions online), I tried customizing the nsmb.conf file.  While I was able to achieve better performance, the reality remains that SMB performance on Mavericks is half the performance of AFP.  The best numbers I got were about 14 to 18 seconds and that was by using some tweaks in the nsmb.conf file.  Sad, but true.

However, I am optimistic that Apple is going to resolve this.  Here is my thinking.  Most OS releases address a bulk of the major issues with the 10.x.2 release.  The 10.x.1 is usually the "oh my go how did we miss that data destroying major bug" fix.  Then, Apple sits down, listens to customers, and then refines the 10.x.2 release introduces significant stability improvements and everyone is happy.

Ah, but Apple missed the mark with the 10.9.2 because instead of focussing on the major issues, Apple focused on the undelivered features promised in WWDC from 2013.  Note that most of the changes in 10.9.2 and Server 3.1 (3.1.1) are around Profile Manager and all the VPP and device management features that Apple announced at WWDC but was not able to deliver with the initial release of Mavericks.  So, in my mind, this pushes the refinement package to 10.9.3 so I am optimistic that we will see some improvement soon.

But for now, I am feeling your pain.  I actually have a customer that has two Windows 7 RIPs (large format printing).  The performance and stability problems have been so bad when connected to the 10.9 server that they have actually resorted to sneaker-net to get files over to the RIPs.  It pains me but I have nothing to offer as a viable solution.  Heck, I even started down the NFS road.

So, yes.  I've seen it.  Oh, watch out for when the SMB clients decide to mangle your ACLs.  That is fun.  But I have also seen Mavericks Server, when allowed to just do AFP, do exceptionally well and handle a significant load.

Sadly, I have no magic bullet on this one other than wait and see how the next release does.  I am lucky that Java and Juniper are such a wreck.  Two large corporate customers have mandated that Mavericks is not supported due to VPN incompatibility so I am barred from upgrading.  This has bough me time.  But sooner than not, the IT crew will upgrade their devices and then we will be expected to deliver Mavericks.  I just hope Apple resolves the issues by then.


Title: Re: File Share Error
Post by: urban420 on April 13, 2014, 01:59:30 PM
I hate to say this, but your post gave me back a little of the sanity I have lost in the past few days trying to get things working as they should be. Not only is performance an issue, but it is like access rights are completely ignored. We just have two PC's so I think I am going to figure out a way to rid myself of SMB and set all the shares to AFP only.

I just find myself questioning why I even bought the Mini Server, or at least why I decided to make the Mini Server the file share server. I foolishly invested in a nice Thunderbolt RAID array that is attached to the Mini Server as I intended to make that our main storage. But at this point it seems like it would have been easier to go with a NAS or even a small Windows Server for the file sharing - at least for the file sharing that needs to be shared among Mac and Windows machines.

And I am cool with finding workarounds, I just hate spending countless hours troubleshooting when it is not something I can even fix. The Mini Server does so many things effortlessly, so to think that it would be file sharing that ends up being the problem is a huge surprise. You would really think that would be one of the things that would be bulletproof.

Thanks again for all the info and you certainly shed some light on many of the things I am struggling with. As I said, I hate saying it but it gives me a little bit of comfort knowing that I am not the only one experiencing these problems.
Title: Re: File Share Error
Post by: mtbuck on November 06, 2014, 06:50:46 PM
Has this stance changed with 10.9.5 / Server 3.2.2?  Is AFP still the recommended protocol? 

In February we forced all filesharing to use SMB.  We had some issues, so recently when I saw this post we changed and forced AFP again.  We seem to be having big issues with AFP.  Our attached RAID Drive keeps disappearing ( & since the move back to AFP, we are having lots of corruption with number files.  Users get a notice that the share doesn't support AutoSave and then gives them the option to save anyways or revert or cancel. None of these options actually work.  We found if you choose "save anyways" a few times, you'll exit the loop and you can duplicate/save-as and save your information in a new file.  But if you don't save your work into a new file, no matter the choice you make (cancel, revert or save anyways) - the original file becomes corrupt (typically the file size turns to Zero k).

Before taking any drastic measures, I'd love to know what others are doing for Apple File Sharing and if you think AFP is still the best protocol to use for now?

Thanks for all the help - your book is very helpful!

PS - Sorry if I should have started a new topic.
Title: Re: File Share Error
Post by: Reid Bundonis on November 06, 2014, 08:25:12 PM
Welcome.  Please realize that this is all my opinion and every environment is different.  Oh, and I should mention that this landscape is changing constantly.

So...  SMB under Mavericks is a double edged blade.  If you are ONLY supporting OS X systems, then it "should" be acceptable.  Performance is nearly on par with AFP.  However...  Once you try to support Windows workstations....  Ugh.  Train wreck.  Disaster.  Plague.

(I should point out here that my testing of SMB on Yosemite is showing performance BETTER than AFP when going Mac to Mac Server.  This is the first time ever that SMB performance has exceeded AFP on a Mac Server.  I am still in the middle of my Windows client testing so I am not ready to reveal results yet.)

Based on this (not talking Yosemite), AFP remains my default protocol in all supported environments running 10.9.x or prior.  I've not moved to SMB because AFP is something that remains constant and customizable.  Plus, I have a number of customers who love their Classic OS legacy.  (Can you say ƒ at the end of a folder name... I know it is a folder.  I've always known it is a folder.  Look the icon is a folder!  I don't need a latin lower f to tell me it is a folder!)  Oh, am I yelling?  And then there is the spaces and special characters...  Oh, boy.  Folders like "     Really important" and "•••••••I am first" to make them bubble to the top.  SMB handles this poorly. 

Now, I will admit, I am lucky enough not to be supporting iWork in any locations.  All my customers are Office users to the core (enterprise compatibility).  So I have not run into the issues you are experiencing.  However, the AutoSave alert is normal for any applications that support Apple's NSDocument autosave.  This includes TextEdit, iBooks Author, Numbers, and others.  So far, I have not seen data corruption with these applications.  The issue is that a network volume does not contain the .DocumentRevisions-V100 folder (look on the root of your hard drive to see what I am talking about).  By the way, this is not to say that Office is perfect.  The locked file bug is making me crazy in mixed environments but I've mitigated it by disabling sleep on all systems.

However, I've never seen AFP drop a RAID.  I see from the thread that you are using a Drobo.  Now this is my opinion, but I've always seen the Drobo as a bad product.  We refuse to sell it to customers and if we run across someone who has one we do everything in our power to get them off it.  (I had one customer with data so critical I ate half the cost of a RAID to get them on something I trusted.)  I still recall Drobo coming to our office way back when they introduced their first product.  The rep said, "a drive can fail and everything keeps working..."  As he said that, one of my techs reached out and ejected a drive (ya, we are those kind of people).  The unit bricked itself and kernel panicked the host.  The red faced tech profusely apologized as he scrambled to save face.  From that point forward, we were skeptical.  Every time we have run across one there has been issues.  Corrupt volumes, unexplained disconnects, drives that just go south and never recover.  I can go on an on.  So my fear is that you are dealing with a component failure, not a protocol failure.  Again, I don't know your environment so this is speculation based on a lot of prior experience.

One way to determine is create an AFP share on the internal drive or a drive other than the Drobo.  See if it fails.  Repeat all your tests.  Remember, you will get the AutoSave alert when saving to any volume.  But create a private share on the boot volume and try there.  See if you can replicate the 0k issue.

If not, then I fear the Drobo is doing to you what I have seen it do to everyone else... DraiNo.  Down goes your data.

So, a future looking statement.  SMB3 in Yosemite "might" be an improvement.  As mentioned, this is the first time Apple removed the checksumming on SMB.  And it is beating AFP so far in isolated testing.

I am glad you are finding the books helpful.  I am working on getting the revision of Control and Collaboration out and am working on the third in the series.  It should be a good one :)

Title: Re: File Share Error
Post by: mtbuck on November 07, 2014, 10:59:23 AM
Thanks for the quick response Reid! 

We are an all-Apple shop (well, there's two machines in the building running windows, one is for the phone system and the other is for Quickbooks - but otherwise the rest are all Apple).  Thanks for the clarification on not recommending SMB for environments with Windows.  It makes me feel more confident switching back to SMB for our Apple environment.

[FYI only - slight clarification] Sorry for not being more clear when I referred to the Apple Discussion board.  I didn't start the post, I just participated in the discussion, as we're having the same issue (my name there is MT Buck).  So, luckily we don't have Drobo drives.  We have a Promise RAID drive attached by Thunderbolt for our filesharing and then a G-Speed Q attached by FireWire 800 for Time Machine back ups of the server & filesharing drive.  I'm not sure your thoughts on them... but saw in your first book that you recommend ExtremeZ-IP.

Anyway - I've learned a ton from your books.  Thank you and keep up the good work.  I also just wanted to add how happy I was when I saw the link to this forum in the second book!  Thanks!


Title: Re: File Share Error
Post by: Reid Bundonis on November 07, 2014, 01:45:07 PM
I am glad the books helped out!  That is great to hear.

So Promise gear is one of our favorites.  Both the FC arrays and the Pegasus.  The price to performance of those Pegasus arrays make it an easy sell and easy to support.  We tend to always ship with a shelf spare drive and so far, so good on those units.  Both the 1 and the 2.  Can't speak highly enough about them.  And with the promiseutil command line tool, you can do anything.

I am not familiar with the G-Speed but I am sure it is fine.

The writing is on the wall for AFP.  Apple has put four years of development into their own SMB client.  Sooner or later, it is going to work properly.  10.7 was a mess.  10.8 got better.  10.9 got worse.  10.10 seems to be better.  Too soon to tell.

In enterprise, 2014 has been the year of the retired Xserves :(  And since there is no hardware that satisfies data center requirements, the options are Windows servers.  I've done just about every migration I can think of this year.  Xserve to Windows Cluster Server.  Xserve to Windows file share.  Xserve to NAS appliances.  Xserve to Windows with ExtremeZ-IP.  In all the Windows cases, the performance of SMB has been as slow as 1/4 that of AFP from the Xserves.  10.9 is faster than 10.8.  But, many users have been very frustrated by these moves.  My hands are tied as the direction of the business is the centralize the file services data on a single platform that they know how to support.  I understand this.  But it remains frustrating.  The best solutions I've seen are the moves to ExtremeZ-IP.  It is the only solution that provides reliable search.

Ok, I am off topic.  Long week and I simply don't feel like doing much today :)  Sorry for the rant on the Drobo.  Over the years we have collected our darlings and our goats.

Hope this helps and keep those OS X Servers running!