Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

awkward_eagle

macrumors member
Original poster
Feb 5, 2020
84
36
I'm using FCP 10.4.8 on macOS 10.15.3 with network storage over 10g SMB across a Mac Pro 2019, Mac Pro 2013 with TB2-10g adapters, a current Mac Mini, and previously an iMac Pro.

Across several project libraries using a wide range of footage I've come to experience network drives suddenly disconnecting when Final Cut Pro goes to render the timeline using Background Render. All other uses of network drives to the same NAS are working fine, including Finder file transfers, editing the same footage in DaVinci Resolve, etc. Apple officially supports SMB and NFS protocols for FCP library and media storage and it looks like this problem applies to both.


It happens most reliably when the source footage is 4k or higher and ProRes 422HQ or higher, making me think that size and data rate is passing some invisible threshold. The same projects with the same footage worked on Mojave using the same NAS and TB3 raids have always worked equally well.

NAS model : QNAP TVS-1282T3


After doing some research it appears others have run into the same problem due to the forced upgrade to Catalina with the new Mac Pro release. Here's a thread on fcp.co that covers this.


This thread references a MacOS fix created by SNS without providing any info, so it appears to be for customers only.


Similarly, the makers of the popular FCP focused Jellyfish NAS have run into the same problem and issued a fix via their configurator app.


Both places have found and confirmed that the root of the problem is MacOS itself and their patches only modify MacOS and not the NAS units. I have a contact who has been trying to get Apple support to acknowledge this as an actionable MacOS problem, but they're placing the blame on the NAS manufacturers because the manufacturers are issuing patches. This ignores that what they're patching is MacOS itself. While this is nice for SNS and Jellyfish users, it leaves Synology, Qnap, and other NAS users high and dry until Apple fixes this assuming they ever do.

My question is if anyone else is experiencing this and can they determine what these patches are actually fixing so that I and other NAS/FCP users can apply the fix.
 
Last edited:
I can confirm the same exact issue and am familiar with all those referenced links. I literally bought a new Mac Pro to use with Final Cut Pro and it is totally useless with my current NAS system. The SMB implementation in macOS Catalina is abysmal and quite shocking considering its reliability would be expected with the user base buying a system like a Mac Pro. Apparently, the issue is less pronounced in earlier macOS versions like Mojave, but people buying new systems like the Mac Pro and new MBP 16 are sorely out of luck.

The irony in the whole situation is that this issue happens under heavy loads (aka editing in Final Cut Pro with high resolution ProRes files) which requires features like 10GbE. So while my new Mac Pro has built in 10GbE its performance/usefulness is being undone by macOS Catalina network support. I have a reproducible sample final cut pro project that will crash and disconnect my NAS mounted drives.

I have called and reported the issue to Apple and at least with me they refuse to acknowledge it as macOS issue and place the blame on all ThirdParty vendors even though the problem happens across completely different hardware solutions and all the fixes so far have been network configuration patches for macOS not firmware/NAS updates.

If anyone else is dealing with this or has at some point dealt with this issue, please call and open a ticket with Apple and report it so they acknowledge the issue. SMB performance/reliability on the Mac is a real issue and needs to be addressed by Apple.

Right now I have revert to editing on an old Mac because my workflow depends on my NAS. In short, if you're workflow uses a NAS think twice about buying new Mac Pro unless your NAS manufacture for sure has a patch that fixes macOS Catalina.

I sure hope that Apple releases a fix soon. This is quite embarrassing for a supposedly Pro solution (Mac Pro + Final Cut Pro + macOS Catalina) that hasn't been optimized and tested sufficiently for normal industry standard workflows.
[automerge]1582819714[/automerge]
Take a look here - this may help.


Unfortunately, these configurations by themselves do not address the specific issues related to this situation. I have tested all the well documented configurations available publicly online for SMB.

That being said, I have reason to believe the current solutions that are being implemented by folks like Lumaforge and SNS referred to in this thread are basically adjustments to default network parameters similar to the ones mentioned. Like the original post says, that information is not currently available to the public as they consider it part of their service to their customers.
 
Last edited:
Take a look here - this may help.


The nsmb.conf modification is a separate problem and has been necessary to use FCP on a NAS for the past few versions of MacOS. Apple even has a support document for this.


An old Creative Cow thread has a more in depth discussion that results in the same edits as the SuperUser thread.


Unfortunately this doesn't address the network drive ejection when under heavy load.
 
Hey Everyone,

I have discovered a fix for this solution. Can't say it works on every hardware configuration, but at least on the newest Mac Pro and the previous gen "trash can" Mac Pro's this solution works.

I have posted the fix in more detailed length here on Apple's Community sight.
https://discussions.apple.com/thread/251102946?page=1

The short of it is that macOS Catalina default system parameters for networking are not tuned for high demand network performance. Apple's macOS (going back as far as OS X Mountain Lion) actually has a built in feature called "Server Performance Mode". I have also posted the direct link to Apple's own documentation.

Server Performance Mode
https://support.apple.com/en-us/HT202528

The solution is as follows:

1 - First check to see if server performance mode is enabled on your machine using this Terminal command. You should see the command return serverperfmode=1 if it is enabled.

Code:
nvram boot-args

2 - If you do not see serverperfmode=1 returned, enter this following line of code to enable it. (I recommend rebooting your system afterwards)

Code:
sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

On my brand new Mac Pro (2019), not only did this fix issues with Final Cut Pro X freezing and disconnecting SMB network volume shares, it increased my throughput performance from 30%-50%. My machine almost reaches the theoretical max throughput of 10GbE. I have also tested this on older machines running Mojave and they also gained performance improvements. I have also tested older "trash can" Mac Pro's upgraded to Catalina that were previously also crashing and disconnecting SMB shares and they too are now working. I can't promise that this will fix everybody's issues, but I can tell you that there is a good chance it will help your overall network performance especially if you are using a high demanding network application. Note: I have not tested this, but if you ever execute an NVRAM reset this option would presumably disappear and need to be re-enabled.


If at any time you want to turn off performance mode use this line of code.
(I recommend rebooting your system afterwards)


Code:
sudo nvram boot-args="$(nvram boot-args 2>/dev/null | sed -e $'s/boot-args\t//;s/serverperfmode=1//')"


Hope this fix helps!

Also, anyone talking to Apple refer them to this fix and let them know we'd all appreciate a more transparent and user friendly way to enable this feature.
 
Hey Everyone,

I have discovered a fix for this solution. Can't say it works on every hardware configuration, but at least on the newest Mac Pro and the previous gen "trash can" Mac Pro's this solution works.

I have posted the fix in more detailed length here on Apple's Community sight.
https://discussions.apple.com/thread/251102946?page=1

The short of it is that macOS Catalina default system parameters for networking are not tuned for high demand network performance. Apple's macOS (going back as far as OS X Mountain Lion) actually has a built in feature called "Server Performance Mode". I have also posted the direct link to Apple's own documentation.

Server Performance Mode
https://support.apple.com/en-us/HT202528

The solution is as follows:

1 - First check to see if server performance mode is enabled on your machine using this Terminal command. You should see the command return serverperfmode=1 if it is enabled.

Code:
nvram boot-args

2 - If you do not see serverperfmode=1 returned, enter this following line of code to enable it. (I recommend rebooting your system afterwards)

Code:
sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

On my brand new Mac Pro (2019), not only did this fix issues with Final Cut Pro X freezing and disconnecting SMB network volume shares, it increased my throughput performance from 30%-50%. My machine almost reaches the theoretical max throughput of 10GbE. I have also tested this on older machines running Mojave and they also gained performance improvements. I have also tested older "trash can" Mac Pro's upgraded to Catalina that were previously also crashing and disconnecting SMB shares and they too are now working. I can't promise that this will fix everybody's issues, but I can tell you that there is a good chance it will help your overall network performance especially if you are using a high demanding network application. Note: I have not tested this, but if you ever execute an NVRAM reset this option would presumably disappear and need to be re-enabled.


If at any time you want to turn off performance mode use this line of code.
(I recommend rebooting your system afterwards)


Code:
sudo nvram boot-args="$(nvram boot-args 2>/dev/null | sed -e $'s/boot-args\t//;s/serverperfmode=1//')"


Hope this fix helps!

Also, anyone talking to Apple refer them to this fix and let them know we'd all appreciate a more transparent and user friendly way to enable this feature.
I wonder what the trade-off is - why is this not always enabled?
 
I wonder what the trade-off is - why is this not always enabled?

As far as I can tell, it may use more memory and maybe some extra overhead on the CPU. The reality though is that I have not seen any noticeable downside in my everyday workflow so far. Maybe on very low-end entry level Macs this could have some adverse affect, but I think based on the research I have done most default system network configurations in macOS are based on hardware from like 20yrs ago. So the likelihood that it would be an issue on any new Mac is probably super low.

My guess is that macOS Catalina by default has been optimized for the lowest common denominator for compatibility and basic stability across new and old Macs. That is probably why it is not enabled by default.
 
As far as I can tell, it may use more memory and maybe some extra overhead on the CPU. The reality though is that I have not seen any noticeable downside in my everyday workflow so far. Maybe on very low-end entry level Macs this could have some adverse affect, but I think based on the research I have done most default system network configurations in macOS are based on hardware from like 20yrs ago. So the likelihood that it would be an issue on any new Mac is probably super low.

My guess is that macOS Catalina by default has been optimized for the lowest common denominator for compatibility and basic stability across new and old Macs. That is probably why it is not enabled by default.

I can confirm that this fix works. My FCP stability and overall network speeds to the NAS have greatly increased.

A quick google search on the Server Performance Mode reveals that this changes the tolerances of simultaneous network connections, packet size, and memory usage which in turn can handle the heavy load FCP puts on the network drivers.

Some sources say System Integrity Protection needs to be disabled to enable Performance Mode, but I've applied the fix to a few computers without having to disable SIP. This might be new to Catalina, but who knows since Apple isn't saying.
 
on a Mohave iMac Pro doesn't seem to work?

serverinfo --perfmode
Server performance mode is NOT enabled.

$ sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"
Password:

$ serverinfo --perfmode

Server performance mode is NOT enabled.

Also tried:

$ sudo serverinfo --setperfmode 1
Password:
ERROR: Server performance mode could not be modified.

I get abysmal upload rates to both Synology 1 Ge and QNAP 10Ge connections, on the order of 15-20 MB/s. Was hoping this would fix ...
 
@HDFan

As awkward eagle mentioned, there seem to be certain configurations that require that SIP be disabled before enabling Server Performance Mode. It's not clear why this is true sometimes and not other times. Some documentation specifies that SIP disabling was needed macOS El Capitan or later.

Just hypothesizing, this could also be related to the security measures introduced with the T2 chip which also controls certain parameters relating to booting security and modifications. My old Mac Pros do not have the T2 chip and I have disabled the T2 chip temporarily on my new Mac Pro. It could also be not related.

Anyhow, I would definitely try disabling SIP and then try to enable Server Performance Mode. I do recommend enabling SIP after Server Performance Mode is enabled as it does protect against some well known security vulnerabilities.
 
Darn. Disabling SIP made no difference:

System Software Overview:

System Version: macOS 10.14.6 (18G3020)
Kernel Version: Darwin 18.7.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Secure Virtual Memory: Enabled
System Integrity Protection: Disabled
Time since boot: 7 minutes



serverinfo --perfmode
Server performance mode is NOT enabled.

sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"
Password:

serverinfo --perfmode
Server performance mode is NOT enabled.
 
Darn. Disabling SIP made no difference:

System Software Overview:

System Version: macOS 10.14.6 (18G3020)
Kernel Version: Darwin 18.7.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Secure Virtual Memory: Enabled
System Integrity Protection: Disabled
Time since boot: 7 minutes



serverinfo --perfmode
Server performance mode is NOT enabled.

sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"
Password:

serverinfo --perfmode
Server performance mode is NOT enabled.

I am not sure what is going on in your case, but realize that server performance mode is not a typical macOS parameter. It's a essentially a variable saved to your NVRAM settings that affects your network settings/tuning on boot. So first of all, make sure you reboot after you use the enabling command. All you are trying to do is add the argument serverperfmode=1 to your nvram settings. It's not hardcoded to your system and will presumably disappear if you do something like an NVRAM reset.

The test for server performance mode is simply a check to see if the mode is being requested in your NVRAM settings. When using the command

Code:
nvram boot-args

It should either return "boot-args" (essentially nothing with no parameters listed to the right)
Or if enabled it should return "boot-args serverpermode=1"

It really shouldn't be difficult to enable and I have enabled it both on macOS Catalina and macOS Mojave(as you are currently trying to do).
 
sorry for bumping this old thread.

for anyone else banging their head against a wall in their failure to enable server mode and finding this thread through googling the "server performance mode is NOT enabled" response:

you NEED Server.app (or at least some remnants of /Applications/Server.app) for serverinfo to behave.

once Server.app was in my /Applications,

Code:
serverinfo --setperfmode TRUE

worked without a problem.

just fwiw
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.