Why Is My Mac Hanging When Copying Files After Upgrading to macOS Catalina 10.15.4?

Frustrated man in front of a computer

UPDATE: This issue was fixed in macOS 10.15.5


Hearing From Our Customers

Are you working on a movie set, transferring hundreds of gigabytes from a camera card to a RAID array? Are you a photographer trying to copy a large project from one volume to another?

If so, you may have already encountered hangs copying files after you upgraded to macOS 10.15.4. When you encounter the hang we are discussing, you can still move your mouse but are no longer able to copy files.

Investigating the Hang

A few days after the macOS 10.15 update was released, we began to hear of “Finder hangs” from DITs (Digital Imaging Technician) on movie sets. They were having their Macs stall when transferring hundreds of gigabytes of video from their 4K and 8K camera cards to their OWC ThunderBlades and ThunderBays. Anytime we hear about this type of problem, we immediately start looking for a cause.

A day later, we were able to reproduce the problem 100% of the time by copying 300 GB of large (10 GB) files from one SoftRAID RAID volume to another. Using a kernel debugger, we determined that the hang was not caused by an error in the SoftRAID driver. We then were able to reproduce the hang on an AppleRAID volume, using the AJA System Test Lite test application.

Once we proved the hang was not a problem with the SoftRAID driver, we alerted Apple engineers to the issue and collected further information to help them with their investigation. I can’t say when Apple will release the fix for this problem, but in the past, when they have been alerted to a hang or kernel panic, they had it resolved in the next update to macOS.

We will update this blog post once we have confirmed that this hang has been fixed in a future release of macOS.

We Discovered a Temporary Work-Around for macOS 10.15.4

If you want to prevent this hang, there is a setting in the computer’s NVRAM, which can be changed as a temporary fix. NVRAM settings are saved in a dedicated chip in your Mac and determines settings such as the audio volume your Mac starts from, the output volume for sound, and which, if any, debugging features are enabled. One of these debug features allows you to disable the part of macOS which is causing the hang. This could result in a 5 – 10% slower read and write performance but will prevent the hang from occurring.

Note: To enable this setting, you will have to disable SIP (System Integrity Protection). SIP is a feature of macOS which offers advanced protection from malware. By disabling SIP, you could be making your Mac more susceptible to malware infections.

The instructions at the bottom of this post show you how to revert NVRAM to the original (default) settings and how to re-enable SIP. I recommend that after you disable SIP and change the setting in NVRAM, you attach a sticky note to your monitor, reminding you to revert these changes once Apple fixes this problem.

Instructions for Preventing the Hang in macOS 10.15.4

Changing the NVRAM setting requires that you disable SIP.

Steps to Change NVRAM so That Hangs Are Prevented

Disable SIP:

  1. Restart the computer and then press the Command + R keys simultaneously, once you hear the startup chime. Keep holding the keys down until the Apple logo appears (this may take up to 90 seconds).
  2. When the menu bar says: “macOS Utilities,” you are booted into Recovery mode. Launch the Terminal application by selecting it from the Utilities menu.
  3. In the Terminal, type the following command:
    csrutil disable
  4. Afterward, the Terminal should display this message:
    Successfully disabled System Integrity Protection. Please restart...
  5. Select “Restart” from the Apple menu to restart your Mac.

Change the NVRAM Setting:

  1. In the Finder, select Utilities under the Go menu and then launch the Terminal application.
  2. In the Terminal window, type the following command:
    sudo nvram boot-args="dart=0"
  3. Restart your Mac normally, without any keys being pressed.
  4. To confirm that your NVRAM settings have been changed, relaunch the Terminal application and type the following command:
    nvram boot-args
  5. Check that the output from the command reads:
    boot-args dart=0

Instructions for Reverting Your Mac to a Normal Configuration

Once Apple releases an update to macOS 10.15, which fixes this issue, you can revert your Mac to the normal NVRAM settings and re-enable SIP.

Reset NVRAM to the default settings:

  1. In the Finder, select Utilities under the Go menu and then launch the Terminal application.
  2. In the Terminal window, type the following command:
    sudo nvram boot-args=
  3. Restart your Mac normally, without any keys being pressed.
  4. To confirm that your NVRAM settings have been changed, relaunch the Terminal application and type the following command:
    nvram boot-args
  5. Check that the output from the command reads:
    boot-args

Re-enable SIP:

  1. Restart the computer and then press the Command + R keys simultaneously, once you hear the startup chime. Keep holding the keys down until the Apple logo appears (this may take up to 90 seconds).
  2. When the menu bar says: “macOS Utilities,” you are booted into Recovery mode. Launch the Terminal application by selecting it from the Utilities menu.
  3. In the Terminal, type the following command:
    csrutil enable
  4. Afterward, the Terminal should display this message:
    Successfully enabled System Integrity Protection. Please restart...
  5. Select “Restart” from the Apple menu to restart your Mac.

UPDATES

Hang fixed in macOS 10.15.5

We have just finished testing with macOS 10.15.5 and have confirmed that this hang no longer occurs.

Hang also observed when copying to a server

Larry Jordan, the renowned creator of education material on video editing and post-production, contacted us after he encountered the same problem transferring a large amount of data from his iMac to a Synology server. He wrote about it in his latest weekly newsletter.

The NVRAM fix disables WiFi on some Macs

We have heard from numerous customers that the above change to NVRAM makes their WiFi networking no longer work. Users have reported this with MacBook Pros which contain T2 chips but it may affect addition Mac models.

If you encounter this problem, you can follow the steps above in the section “Instructions for Reverting Your Mac to a Normal Configuration.” You can then disable the Write Cache in the SoftRAID driver. This will prevent the hang from occurring but the write performance of your volume will be significantly decreased.

To disable the write cache in the SoftRAID driver:

  1. Launch the SoftRAID application.
  2. Select Preferences from the SoftRAID menu
  3. Select the RAID tab at the top of the Preferences window
  4. Unselect the checkbox next to “Enable write cache” so no checkmark appears in the box.
  5. Click the Save button at the bottom right of the Preferences window.


LEAVE A COMMENT


  • Tim,

    This video by Mark Coughlan, who tested a Thunderbay 4 with 10.15.5 (see ~8:40), indicates problems persist with large file copying, whether on Ethernet or via direct Thunderbolt connection. https://www.youtube.com/watch?v=z_FKJkF5Vfw

    He’s an experienced technical architect and seems to post fair reviews.




  • Oy … I just purchased a Thunderbay 4 and am running it in JBOD mode.

    Will this affect me?

    I’m currently running a 2017 iMac 5K/64GB/3TB Fusion core-i7@4.2ghz Radeon Pro 580 8GBk, but was planning to see what iMac shows up at WWDC (which is rumored to have a T2 chip).




  • Still crashing now even more




  • I’ve upgraded to 10.15.5 and undid everything here. I got my wifi back, but I still can’t unlock my mac with Apple Watch and also Airplay and even marking up a screenshot from macOS on the iPad still doesn’t work. I suspect this has to do with what was previously disabled, even though I re-enabled SIP and undid the NVRAM thing. I’ve reset NVRAM on boot up and am on the verge or reinstalling the OS, unless anyone has a better suggestion.




    • If you want to confirm that your settings are back to normal, you can type the following commands in a Terminal window:

      Typing csrutil status

      should output:
      System Integrity Protection status: enabled.

      Typing nvram boot-args

      should output:
      boot-args

      If both of these commands produce the output as shown above, you have successfully removed the work-around.




  • So I updated to 10.15.5 – can anyone confirm that we still have to revert the Mac back to normal configuration or does the update take care of that?




    • You will have to remove the boot-args in nvram and re-enable SIP (System Integrity Protection) by yourself. The section entilted “Instructions for Reverting Your Mac to a Normal Configuration” in the blog post tell you how to accomplish this.

      The update will have no affect on nvram or SIP.




  • This doesn’t sound good ! I was hoping that 10.15.5 fixes the problems from 10.15.4 but unless your setup is unusual it seems like the bug remains ?




    • The fix in macOS 10.15.5 does indeed fix the problem when copying files to a AppleRAID or SoftRAID volume. I have yet to determine whether this also fixes the similar problem of copying files to a server over 10G Ethernet.




  • I spoke with Joe re the 8062 and he indicated that the 8062 error was related to Time Machine.

    He asked me to turn off time machine and try again. I turned it off and still got the 8062 error.

    In the last 6 years I have never had a problem where there was a file lock issue conflict with time machine. I regularly just copy my iCloud folder to an external drive.

    I am copying the same folder to a regular external USB Drive like I normally do but have left Time Machine turned off.

    If that is successful I will turn time machine back on and try the copy again.

    A grizzly system engineer taught me when I was young, always look to what has changed first.

    I set up a call with Apple 2nd level for tomorrow at 10:30.




  • After updating MAC to the released 10.15.5 and updating the Driver to 5.8.3 on a Late Oct 2013 MacBook Pro I went to copy 200GB.

    I got a:

    The operation can’t be completed because an unexpected error occurred (error Code -8062)

    It got about 80% done. I was giddy and then my hopes were dashed.

    I had done the workaround on the advice of OWC but I understand it was not necessary as I do not have a T2 Chip.

    I have not reversed it yet.

    I am running Validate.




  • Is the hang while copying to a server that is described above by Larry Jordan a different issue, or part of the same? Or, more specifically, did the 10.15.5. update address that also?




  • I’m still seeing these kernel panics on 10.15.5 beta 5.

    Whenever there is a lot of disk activity, for instance Backblaze scanning and backing up an external drive, which transfers data to the internal SSD, the OS crashes after around 400 GB.




    • After looking at your panic logs, I can determine that what you are encountering is not related to the bug we originally observed with macOS 10.15.4.




      • Thanks again Tim,

        I ran several hardware diagnostics (TechTool Pro, DriveDx, Apple Hardware Test, Disk Utility, …) and it’s supposed to be all good.

        Since I haven’t been able to reproduce the panic after going from 10.15.5 beta 5 to 10.15.5, I guess something else changed and that it was another (unrelated) bug.




  • kills my wifi for latest gen mac mini




  • Has the fix been retained in macOS 10.15.5 beta 4?




  • This saved me, thank you. My 2018 Mac mini with Radeon RX Vega 56 8 GB eGPU in a RAZER Chroma enclosure and OWC RAID running SoftRAID was crashing / locking up in hideous ways whenever I’d do a Final Cut Pro X multicam edit with more than four streams. Unfortunately this did disable wifi, but the only real side effect of that is I can’t use AirDrop right now. Small price to pay!




  • When you say ‘had no affect’ do you mean wasn’t still set or was shown as being set but didn’t resolve the issue?

    For me I see it as being set:

    rick@spamspam-1 ~ % csrutil status
    System Integrity Protection status: enabled.
    rick@spamspam-1 ~ % nvram boot-args
    boot-args dart=0

    and so far I haven’t experience the Finder / SSD access hangs as had previously happened 2-3 times a day. However agree that’s not conclusive.




  • Seems you can just set the boot-args in recovery mode and they are preserved in normal. So in recovery terminal just od:

    nvram boot-args=”dart=0″

    (no sudo). This still shows up when checking in terminal after a reboot.

    This way you don’t need to disable SIPs

    See here:
    https://apple.stackexchange.com/questions/315120/setting-a-nvram-variable-in-normal-boot-not-permitted-but-allowed-in-recovery-mo




    • In our testing, setting “dart=0” in NVRAM had no affect if SIP was enabled.

      As of yesterday, I think the best option is to sign up for a Apple Developer account and install macOS 10.15.5 beta 3. This latest beta release fixes the issue so you could remove the nvram setting and re-enable SIP.




  • Beta 3 for Catalina 10.15.5 beta 3 was released today. The ReadMe appears to indicate this issue was addressed.




    • Thanks for alerting me to this. We are downloading it now and will verify the fix is complete. This will take us a couple days of continuous testing. Once we are certain it is fixed, we will update the blog post with our testing results.

      Tim




  • Daniel – I have two Thunderbay 6 and one Thunderbay 8 and had the same problem that you describe. I did a clean install of 10.15.3 more than a week ago and I have not had any problems since then.




    • Reverting back to macOS 10.15.3 will prevent this hang from happening. We have a test which causes a Mac mini to hang in 15 minutes when copying files with macOS 10.15.4. We can run the same test for 7 days without encountering a hang. The hang is definitely the result of a change introduced in macOS 10.15.4.

      If you can revert back to macOS 10.15.3, that is definitely the safest way of avoiding this problem.

      Tim




  • Well, the problem continues. I previously wrote in this thread that I was having problems with my Thunderbay6 RAID arrays. I later stated that disabling the “enable cache” seemed to have fixed the problem.

    Well, unfortunately, it didn’t. I’m still have much more infrequent RAID/computer hangs.

    Not sure what to do at this point, but any suggestions would be welcome.

    Thanks,

    Darral Freund




    • After I wrote the update suggesting that the alternate solution was to disable the write cache in SoftRAID, my tester reminded me that changing this setting makes these hangs much less frequent but doesn’t make them completely disappear.

      I believe that these hangs will also be less frequent with a RAID 0 or RAID 1+0 volume than with a RAID 4 or RAID 5 volume. A RAID 1+0 volume gives you the advantage, like RAID 4 and RAID 5, of being able to still access your files after a disk failure. The disadvantage is that it results in a smaller volume, with a given set of disks, than RAID 4 or RAID 5.

      Ultimately, the true fix has to come from Apple as a macOS update. They are aware of the problem and they usually fix hangs like this in a timely manner.

      Tim




      • I was able to verify the entire volume using SoftRaid. It took about 11 hours, but completed without incident. It did find a few parity errors, but was able to fix them.

        I’m going to try and do some photo editing and processing tomorrow so we’ll see if it works well enough…

        Thanks,

        Darral




  • My experience: I am doing a copy from a Drobo 5D3 to a five bay StarTech enclosure managed by SoftRaid. I started the copy operation with a 17″ “Late 2011” Macbook Pro running High Sierra.. All worked well but because of the age of the Macbook, it was taking a very long time to copy over 100,000 RAW photos and about 3000 video files.

    To speed things up this week I purchased a brand new Mac Mini running of course Catalina and went through the processes outlined to avoid the finder lockup issue. I hooked everything up and both the Drobo and the StarTech were recognized by the OS and SoftRaid saw the RAID 5 volume.

    Thinking all was well, I resumed the copy where it left off on the MacBook Pro. For the first few minutes, I was very happy! The copy was taking half the time it did on the Macbook Pro.

    Then, I got the finder hang, even with all the workarounds in place and verified with support. After letting the “hang” sit there for about 30 seconds, I get messages from SoftRaid indicating that the volume has been disconnected (not by me) and then all the drives and the volume went “red” indicating errors.

    After a reboot and another try, the exact thing happens.

    So, now I am back on the MacBook Pro and everything is working fine again.

    I don’t know if this is because the particular Mac Mini I received was so new and maybe had different firmware or what, but the fix/workaround did not work. SoftRaid support indicated they did not know what would cause the disk to appear ejected and I should check my cables.

    Bottom line, I now have a brand new Mac and a hope that 10.15.5 will fix the issue.




    • Your 17inch MacBook Pro uses USB 2, so it can’t go any faster than 40 megabytes per second. Your new 2018 Mac mini (my favorite Mac in the current lineup), can transfer at 500 – 1,000 megabytes per second over USB, depending on the speed of your enclosure.

      If your disks are all disconnecting on the Mac mini, it is probably a hardware error with one of the storage enclosures. Copying files with your 17 inch MacBook Pro is most likely masking this problem as its USB bus is running so slow.

      I suggest you contact SoftRAID tech support by using our web form at: https://www.softraid.com/pages/support/contacting_tech_support.html

      One of our support engineers can help you diagnose the problem you are having copying files to your SoftRAID volume on your new Mac mini.

      Tim




  • I have a MacBook Pro (15-inch, 2018) with two Thunderbay6 RAID arrays (RAID 5). I’m running Catalina 10.15.4 and Softraid 5.8.3. I hadn’t used the RAID arrays in a while (I shoot sports photography) and when I uploading some files yesterday morning my MacBook Pro hung as described above. After several tries, it became clear it wasn’t possible to perform large file transfers (> ~ 10GB) without the system or the drive hanging.

    I made the fix described above, and my WIFI no longer worked — it was disabled and I couldn’t enable it in the Apple Settings.

    After making and restoring the change to the NVRAM several times, I found that the setting NVRAM boot-args=”dart=0″ is what shuts down the WIFI. I tried googling what that command does, but couldn’t find any useful information. After resetting the NVRAM, but still with the T2 chip and SIP disabled, the RAID array still hung on large file transfers.

    I contacted MacSales support, and they suggested, disabling the “enable cache” setting in the Softraid preferences.

    That seems to have done the job — disabling cache. I was subsequently able to transfer about 680GB to the RAID array without problems.

    I see that in a recent post, someone else disabled the cache, and it worked.

    My question is if I still need to have the SIP disabled for it to work? It bothers me disabling all the security features on my MacBook, so if I no longer have to do so, please let me know if your fix worked without the SIP disabled.

    Thanks,

    Darral Freund




    • Thanks for investigating this so thoroughly. You can re-enable SIP when you return the boot-args setting to their normal value.

      The “Disable Write Cache” setting in SoftRAID does not rely on any NVRAM settings nor does it require SIP to be disabled. It uses normal macOS coding practices and has been a feature of SoftRAID since 2014. I added it for exactly this reason, to work-around problems with storage buses / devices which were used for a RAID volume.

      Tim




  • I see the comments about the work around affecting WiFi but does it affect hard wired Networking as well?




  • I made the changes to my NVRAM and SIP. Everything works fine, including another issue I was having with my OWC Thunderbolt dock: I had trouble with it recognizing or mounting any disk I put in. I would have to put in the disk numerous times, restart to the computer before finally mount. Now the bad news is that I had to change back my NVRAM and SIP because it shut off my WIFI. Of-course that causes numerous issues, like programs that won’t operate unless you connect to the internet. So I’m back to square one, until they get a fix.
    I did unselect the “Enable write cache” on Softraid and my ThunderBay RAID hasn’t crashed yet. Let’s see if that hold up.
    What a mess!!




    • This might just be what happens when you ask a large group of Apple engineers to work from home and after that, get them to create an update to macOS. I know it is rough for everyone. I think the next OS update will be a lot better.

      Tim




  • Would using Carbon Copy Cloner be another workaround without as much hassle?




  • After updating to OS X 10.15.4 I began having this issue as well while in the middle of “ingesting” (I use PhotoMechanic 6 for this) from SDXC and XQD media simultaneously to an OWC Thunderbolt 6 and a Drobo 5D array.

    Up until now my solution has been to turn off the computer, wait a minute to restart and begin again.

    As the second attempt always works without fail, I think the problem must be some garbage that accumulates in the process.




  • Is this just copying to softraid volumes, or any large file copy using catalina?

    How about if the copy is performed using a backup app like CCC? I do all of my important large file copies with CCC (folders as source) and then can use the checksum feature at the same time.




    • This was first seen using ShotPut Pro by DITs on movie sets, so it is not just finder copies. I think it has been seen with CCC as well.

      We have seen it when writing to AppleRAID and SoftRAID volumes.




    • As noted in the Update in the Update: section of this blog article, Larry Jordan, the renowned video editor and educator, observed this hang when copying large files to his Synology server. This shows that this problem does not just affect locally attached RAID volumes.

      The users who initially reported this issue, reported it while using ShotPut Pro and Carbon Copy Cloner.




      • Sorry I should clarify, is it just copying to RAID volumes, or with regular ‘single’ drives as well? I might have missed it the article/comments but I can only see RAID mentioned.




        • We have observed it copying files to SoftRAID and AppleRAID volumes. Larry Jordan has seen it copying files to a server. We have not tested extensively with non-RAID volumes.




        • I am seeing a similar and consistent problem trying to copy any files of even a measly 130MB between two external drives connected to my computer via USB hub (yes, the hub is powered). The files will copy to and from my computer just fine, but between the two external drives, it fails. 10.15.5 does not fix the issue, nor does the work-around in this article, sadly, but this article is the first I’ve seen even close to the problem I am experiencing.




  • What were the AJA Testing parameters (so I can try to duplicate on my system)?




    • I create an encrypted APFS volume using an AppleRAID stripe (RAID 0) with 4 SATA HDDs in a Thunderbolt 3 enclosure. Then I launch AJA System Test Lite and use the following settings:

      Resolution: 5120×2700 5K RED
      Test File Size: 64 GB
      Codec Type: 16bit RGBA
      Target Disk: the APFS encrypted volume
      Settings->Start Test: Runs continuously, Disk Test: Single file, Disk Cache: Disable

      In my testing, this configuration will kernel panic in less than 8 hours.

      My tests were run on a 2018 Mac mini with 4 Hitachi 8 TB disks in an OWC ThunderBay 4.




    • The settings in AJA System Test Lite are: Resolution = 5120×2700 5K RED, Test File Size = 64 GB, Code Type = 16bit RGBA, Settings, Start Test = Runs continuously.




  • My question is, why would a video professional, or any professional, upgrade their work machine(s) to Catalina (or any version of the macOS) without thorough testing? At a minimum they should have a backup of their previous, functional, system to restore from. Otherwise they don’t deserve to call themselves professionals. It’s an amateur mistake.

    That said, why didn’t Apple find this flaw in their pre-release testing? It’s hardly a minor issue, especially considering their renewed commitment to creative professionals – in their hardware if not in their software.




  • I just went back to 10.15.3 and that solved the problem !




  • Doing this disables all network access on my 16-inch MBP




    • If you are having problems with the proposed work-around, I suggest you follow the instructions in the section entitled “Instructions for Reverting Your Mac to a Normal Configuration” and return your Mac to its normal settings.

      You can then either, restore to macOS 10.15.3 from backup or reinstall macOS 10.15.3 from a saved copy of the macOS 10.15.3 installer.

      In our testing, we found that this problem most often affects users with SoftRAID RAID 5 volumes, although it does occur less frequently with SoftRAID and AppleRAID RAID 0 volumes.

      If you are using a SoftRAID RAID 5 volume, you can decrease the likelihood of encountering this hang by disabling the unselecting the “Enable write cache” setting in the RAID tab of the SoftRAID application preferences. This make the hang much less frequent at the expense of decreased write speeds.

      Tim




      • I have a problem with my 16inch specifically and reading/writing to external NVME drives. Carious drives, enclosures, cables have all been tested. I can’t replicate the problems on my other systems running Catalina and or Windows. It’s fundamentally flaw in Catalina or the T2/hardware. That no one has been able to help me with.
        I have tested all versions of Catalina and the problem persists.

        This looked to be a solution for my problem as it seemed quite similar to my issues. But it’s not.




    • It disabled my WiFi too on my 16 inch MacBook Pro. What a mess!




    • I had the same problem with my 16 inh MacBook Pro. No WiFi. What a mess!!