Logsi

Q: File Sharing Grinds to a Halt in Yosemite

I've been having a problem since 10.10 whereby out of the blue our Mac Mini fileserver just grinds to a halt and whenever someone tries to access files in the finder on their client Macs it will just hang and beachball.

 

I've troubleshooted a little bit from having to reboot the server to now ejecting the culprit client off the network This then speeds the network back up again but there is no way to tell which client will be the one that's caused the issue so i have to quickly run around the office and check everyones finder and the problem Mac will be the one that's a tad slower to load files in the finder than others. It's almost as if the computers are DoSing our own server which then slows down the network. There is no way to replicate this issue it seems and comes totally out of the blue.

 

We mainly have word and excel files on the server. We are connected via SMB with AFP turned off. I don't think this issue happens if we're all on AFP but different issues happen with AFP like not being able to save documents and we also need SMB on.

 

All clients are on 10.10.3 and the server is also on 10.10.3.

Posted on Apr 30, 2015 2:28 AM

Close

Q: File Sharing Grinds to a Halt in Yosemite

  • All replies
  • Helpful answers

first Previous Page 4 of 4
  • by Patto,

    Patto Patto May 17, 2016 9:31 AM in response to Logsi
    Level 1 (4 points)
    May 17, 2016 9:31 AM in response to Logsi

    My suspicion is that it is related to SMB file sharing - or less likely - the multicast component of Bonjour. I'm in the process of forcing server clients to use AFP for a trial period. Its not easy because we must still run SMB on the server for PC access and  the Finder defaults to using SMB when connecting via the Sidebar.

    SMB is under suspicion because ->

     

    • the prevalence of the following error when a Mac is 'offending' >

              SMB2","143","Notify Response, Error: STATUS_INSUFFICIENT_RESOURCES".

    • A packet capture of an offending Mac showed around 50% of the packets were related to SMB despite no obvious file sharing activity.

    • the timing of Apple messing with their SMB implementation and the onset of issues.

     


    I have been lucky enough to find myself on-site during a slowdown and gathered Wireshark captures and Apple Data Capture of the offending machine and the machine doing the speed test. Sadly, Apple Engineers and Enterprise are completely uninterested. You might think they would have an interest in looking at the issue when others have handed the data to them 'on a plate'  - but no.

  • by Logsi,

    Logsi Logsi May 18, 2016 1:52 AM in response to Patto
    Level 1 (5 points)
    May 18, 2016 1:52 AM in response to Patto

    The problem with using AFP is that it seems to cause a of a lot of problems with Office programs. The worst being the "Document not Saved" issue. We're forced to use SMB here not due to having windows computers but because of the aforementioned issue.

     

    It is odd that Path Finder doesn't cause this issue and the clients who i have rolled this out on have no problems with the weird DDoS of SMB requests now. What does finder do that Path Finder doesn't?

     

    Clients are creatures of habit and even if you made path finder look and behave the same as finder it still will cause confusion and headaches.

     

    I'm hoping that if i upgrade the server to El Cap 10.11.5 it may fix it but i doubt it.

     

    The only saving grace i have is that i can quickly diagnose and rectify the issue happening...

  • by Patto,

    Patto Patto May 18, 2016 2:32 AM in response to Logsi
    Level 1 (4 points)
    May 18, 2016 2:32 AM in response to Logsi

    I hear you - however I've recently gained a greater understanding of the issue saving Office docs.

    There are at least two potentials issues that can arise when saving Office 2011-6 docs.

    1) the invisible lock file that is created when someone opens a doc to prevent others saving over the top of the same file, This file is sometimes not deleted making it difficult for anyone to save.

    2) The invisible .TemporaryItems folder - I have posted this on Microsoft's Technet discussion and it goes something like this >


    Boring But Necessary Preamble

    Each User in Unix has a computer account ID number which is unique to the machine on which it was created. 

         These numbers normally start at 501 for the first user and increment as additional accounts are created.

    (Network accounts held on the server start at 1001.)

     

    This ID can be viewed by going to  System Prefs > Users

         Unlock the Account and secondary-click on the account name >

     

    As mentioned - these numbers are unique to each machine - but won’t be unique on a network. Network accounts held on the server will however be unique because they reside in one location.

     

    The Problem

    Now here is why this can be a problem…

     

    Microsoft Office products create a hidden folder at the root level of every share-point called .TemporaryItems.

     

    Inside .TemporaryItems a subfolder is created for each user. These subfolders are named using the AccountID number of user that accesses the server from the Office product.

    folders.501

    folders.502

    folders.503…


    With multiple workstations it is highly likely that these folders will be accessed by more than one user with the same ID - each claiming read/write access to the same folder potentially at the same time. This can cause ‘file in use’ errors and prevent the saving of a file.


    You might think this setup was designed to fail!

     

    Now the question is - how best to prevent these conflicts? The answer has yet to be determined?

    The brute force method of deleting these folders seems to work - thereby proving the theory - but is not an ideal solution


    Now - neither of these behaviours should change between AFP & SMB


    So closer - but no solution yet.

  • by Logsi,

    Logsi Logsi May 18, 2016 2:36 AM in response to Patto
    Level 1 (5 points)
    May 18, 2016 2:36 AM in response to Patto

    Thanks for the information! It's valuable to broaden knowledge of the system infrastructure.

     

    We haven't had any locked files for editing since using SMB, it solely seemed to be a AFP issue with ghost files starting with -$. Saying that, the later versions of OS X seemed to fix this also with the successful deletion of the ghost files.

  • by Patto,

    Patto Patto May 18, 2016 3:29 AM in response to Logsi
    Level 1 (4 points)
    May 18, 2016 3:29 AM in response to Logsi

    The files starting with ~$ are different again. These files are temporary files stored in the same directory as the file being edited adn are not invisible.. Those files will remain if the doc being edited was not closed 'gracefully' They can be deleted so long as the recovered doc contents are ok. All these 'working' files (invisible or otherwise) are of course a complete pain to manage. It's unclear to me when each of the 'non-lock' temp files come into play. i.e. when is the folder.userID folder used vs creating a ~$ file. I also suspect that any variations in this behaviour caused by AFP vs SMB may change depending on the version of the OS and/or the version of Office?.

  • by Logsi,

    Logsi Logsi May 18, 2016 3:34 AM in response to Patto
    Level 1 (5 points)
    May 18, 2016 3:34 AM in response to Patto

    Thanks for the clarification.

     

    Another problem has reared it's ugly head with the introduction of 10.11.5 on client machines. When they connect via SMB, after a while they can no longer move files around and throw an error complaining about the password not being correct. Disconnect the server storage and connect via AFP and it's fine...

  • by Patto,

    Patto Patto May 18, 2016 4:17 AM in response to Logsi
    Level 1 (4 points)
    May 18, 2016 4:17 AM in response to Logsi

    The network I'm referencing is mostly still on Yosemite - but it fills my heart with a 'Death Of Prince' kind of sadness that Apple's management of networking protocols seems to be continuing a downward trajectory - like a number of other aspects of their software ecosystem, It seems that the old AFP is still the more robust protocol - assuming it can accomodate saving Office docs. I've noticed a number of weird behaviors with SMB since it became the default networking protocol - apart from LAN slowdowns. My strategy going forward is to attempt a combination of AFP and Office 2016 and see what happens. It shouldn't be this hard to get a mid-sized office network doing mostly word processing, spreadsheets, web browsing and mail to  function reliably in 2016 !

  • by Logsi,

    Logsi Logsi May 18, 2016 4:33 AM in response to Patto
    Level 1 (5 points)
    May 18, 2016 4:33 AM in response to Patto

    You would have thought...Office in a Mac environment and network shares just does not work smoothly.

     

    Office 2016 is still dire after all this time since it's inception back in March 2015. We're still using a combination of Office 2011, Office 2016 and even parallels 11 with Office 2016 and Office 2013...

     

    I'm getting close to resorting to Windows Server and Boot camping everything in here to Windows for an easy life. I'm sure the grass isn't greener however...

  • by Patto,

    Patto Patto May 18, 2016 5:03 AM in response to Logsi
    Level 1 (4 points)
    May 18, 2016 5:03 AM in response to Logsi

    I'm yet to call Office 2016 dire - but it is early days. I haven't noticed any backward steps so far. I am in the process of migrating users (including myself) from Apple Mail to Outlook 2016. Apple Mail is another classic example of the demise of Apple's 'essential app' software.

     

    The El Capitan version of Mail in combo with Office265 Exchange servers is embarrassingly bad. How it was ever released is beyond me. Outlook 2016 seems very useable despite a number of strange deficiencies. For uploading locally stored mail to Exchange and general robustness - is way ahead of El Capitan Mail.

     

    Recently I had an extended discussion with a senior Apple support person who explained that if a mailbox is corrupted because a user quits the app while a sync was in progress - then they are deliberately trying to break the app and should expect problems!!!. That is despite the fact that there is no feedback to the user that the sync is even happening! This makes an interesting deviation with the Apple Human Interface Guidelines outlined in the 80s - am I too cruel?

     

    MS dooo seem to be 'on the case' when it comes to updates. The biggest deficiency of Office 2016 is probably the lack of support for CardDAV and CalDAV - and that might persist. MS seem to be focussing their efforts on migrating users to Office365 - including existing Windows servers. To that end it will be important for them to have desktop support for as many people as possible I would have thought - including Mac users.

  • by Patto,

    Patto Patto May 18, 2016 5:09 AM in response to Patto
    Level 1 (4 points)
    May 18, 2016 5:09 AM in response to Patto

    BTW: If been through this process before - towards the end of OS9 before Jobs came back - the OS was becoming very unstable with people fleeing the platform - then OS X was released. Maybe things have to get REALLY bad before they get better. The sun cannot rise until it sets.

  • by Logsi,

    Logsi Logsi Jun 15, 2016 4:12 AM in response to Logsi
    Level 1 (5 points)
    Jun 15, 2016 4:12 AM in response to Logsi

    I'm 99% certain that this issue is caused by finder now. I've switched troublesome clients to Path Finder and voila. No more problems from those clients.   In the last month i've been forced to use El Capitan on a server switchover as one went down and this didn't solve the problem either

     

    P.S. This new layout is awful...

  • by Patto,

    Patto Patto Aug 4, 2016 9:48 AM in response to Logsi
    Level 1 (4 points)
    Aug 4, 2016 9:48 AM in response to Logsi

    I've made it easier for clients to use AFP and that seems to fix the problems in Yosemite. It's not a solution - just a work-around. There is no way of stopping clients connecting when they use the Finder sidebar to connect unless SMB is turned off on the server. Maybe Path Finder is causing more users to connect with SMB?

first Previous Page 4 of 4