final cut pro 12.3 is failing to render to network shares

We're using an M4 MBP connected to an OWC 10GbE NIC to our network, with an M4 Studio that has a couple 192TB DAS and one 4TB external SSD in an OWC 1M2 case. We're trying render a 900GB source file (from a DAS on the Studio) that is SDR and converting to HDR in ProRes 422 HQ to the 1M2 SSD (which will take like 2.5TB of space), but FCP barfs within the first two minutes but doesn't give up any info on why.

There IS some stuff in the log file that implies there's a dirty cache that can't be emptied? But we're not sure. Below is a snippet from the log file:

Event: disk writes

Action taken: none

Writes: 2160.48 MB of file backed memory dirtied over 2503 seconds (863.04 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds

Writes limit: 2147.48 MB

Limit duration: 86400s

Writes caused: 2160.48 MB

Writes duration: 2503s

Duration: 2503.35s

Duration Sampled: 2502.38s (event starts 0.77s before samples, event ends 0.21s after samples)

Steps: 452 (5 samples lost, 10.49 MB/step)

Hardware model: Mac16,7

Active cpus: 14

Memory size: 48 GB

HW page size: 16384

VM page size: 16384

Shared cache residency: 29.42% (1973.33 MB / 6707.41 MB)

MacBook Pro (M4 Pro, 2024)

Posted on Aug 25, 2026 10:12 PM

Top-ranking reply

joema

Level 4

1,643 points

Posted on Aug 28, 2026 12:08 PM

Recommendations:

Export to a local volume, then copy to the share.Internal SSD or the OWC Atlas — anything local. This fully decouples the encoder from network stalls and will work every time. For this workflow (single ProRes file, no re-render) the extra copy is minutes. This is the reliable fix; everything below is about making direct-to-share exports survivable.

Quiet the Mac Studio during exports.Pause Plex Media Server (its scanner was at 90%+ CPU), and exclude the big media volumes from Spotlight on the Studio (System Settings → Spotlight, or mdutil -i off per volume). mds_stores has logged repeated high-CPU incidents indexing ~300 TB of attached storage, and it competes directly with smbd for the arrays.

Test the same export to an APFS SSD share on the Studio. Share a folder on the OWC Atlas Ultra (or internal SSD) and export TEST.mov to it. If that succeeds where ItTwerks fails, the bottleneck is confirmed as the HFS+ Pegasus write path, not SMB or the network. The often-seen commentary about not using APFS on mechanical drives is outdated. APFS is now the recommended volume format for both mechanical and APFS drives.

Treat the 168 TB HFS+ volume at 77% full as suspect.HFS+ at this scale and fill level allocates slowly and fragments badly, and allocation stalls block all I/O on the volume. Check it with DiskWarrior (already installed), and plan to keep large HFS+ arrays below ~80% — or migrate the export-target role to APFS.

Don't read the source and write the export over the same share at once.Source (ProRes LT) and destination are both on ItTwerks, sharing one SMB session and one array. Keeping the source local for the export halves the load on the choke point.

top tuning the network — it isn't the problem.Jumbo frames, EEE, AVB, flow control: the link negotiated 10Gbase-T full-duplex cleanly and never flapped during the failure. Use smb:// (never cifs://) and leave the NIC settings at the combination that benchmarks best.

Misc Observations and Comments:

Four cifs:// connection attempts (09:29–09:31) were refused with "cifs specified but SMB 1 is not enabled." Someone is connecting with the legacy cifs:// scheme, which forces SMB1. Always use smb://. The working mount authenticates via Apple ID over Bonjour (ThunderPuckExtreme._smb._tcp.local).

On the Studio, EtreCheck flags SIP and Gatekeeper disabled, security updates off, mds_stores and apfsd high-CPU incidents, and a cracked-source Logic install ("FileCR"). None of that caused this error, but it's a fragile machine to use as a production file server.

View in context

63 replies

Aug 30, 2026 9:09 AM in response to minecraftiaMACUser100

NOOO IT STILL FAILED..

It got further than it ever has though, 4%. Same 2TB export.

I am so sad..

Edit:

I also tried the same test export, but with the destination being one of the SSDs over the network on the Studio. Of course, that failed before 2%.

So this means conclusively that FCP has this bug, and it is separate from the 8GB MacOS bug, however the 8GB bug does make the FCP one about 2-3x worse.

Aug 30, 2026 11:38 AM in response to joema

Huh, that's weird. I am working with 8K60 footage though as I mentioned, so that's probably the difference, although.. why you can't make it fail with bitrates higher than I was working with long ago when I first ran into the FCP bug is perplexing. Maybe I just had worse drives. My NAS was awful at the time, so that could've been part of it. Yea retest with 8K60 ProRes.

You're telling me that in your testing, from the first Mac to the 2nd Mac, in Finder, to the mechanical RAID, you experienced NO SLOWDOWNS when copying data 16GB or larger? No drops at all? That's the graph I was most interested in. I have slowdowns in ALL TESTS between ALL MACHINES like this. Every 8GB, without fail, if the destination disk is shared by a Mac. I do not get it on the new NAS system we bought.

joema

Level 4

1,643 points

Aug 30, 2026 11:56 AM in response to minecraftiaMACUser100

I've seen no major slowdowns so far. However, I edited my above post and removed the graph because I want to re-test that. My prior statements about an FCP writing rate limit when encoding to ProRes 422 or HQ were incorrect. My M1 Ultra can export at nearly a gigabyte per second to the local SSD.

I need to find where the 90 MB/sec to 110 MB/sec limit came from when encoding via 10G to a server.

I have some command-line I/O monitoring utilities I can send you, but I just wrote them, so they need some further refinement. I'll go through them over the next 24 hr and get in touch with you.

Aug 30, 2026 1:42 PM in response to joema

It would be way faster and better if we got in touch directly some other way, as in, not on a forum, so we can figure everything out. Maybe schedule a call or something? I also want to make excruciatingly sure the details are correct before you go through the effort of testing again.

Aug 27, 2026 2:23 PM in response to terryb

bruh

terryb

Level 4

3,736 points

Aug 27, 2026 4:49 PM in response to Old_Video_Guy

I noticed that too but figured it was either a typo or there was some other reason OP wants to do this.

Aug 28, 2026 1:15 AM in response to minecraftiaMACUser100

terryb

Level 4

3,736 points

Aug 28, 2026 9:28 AM in response to joema

Thanks joema. I hope @minecraftiaMacUser100 takes advantage of your very kind offer. I'm really curious to learn what the issue is.

Aug 28, 2026 9:40 AM in response to joema

I for sure will. The files are uploading right now to that link provided. Thank you. I don't know exactly which side you wanted logged, so I'm assuming my laptop (the one I'm editing on).

Aug 28, 2026 11:48 AM in response to joema

I'm not seeing some of these posts when I'm not logged in. What's up with that?

BenB

Level 6

13,716 points

Aug 28, 2026 1:09 PM in response to terryb

I don't use network drives, I can't test this. But I have two MBPs I could connect an ethernet cable to and try it over the weekend.

Aug 28, 2026 3:51 PM in response to joema

We already know all of this from the previous posts by me in the thread. Redundant information confuses people.

Aug 28, 2026 4:57 PM in response to Norman Lemieux

Wow, I just noticed that it's using my real name. Can you all see that, or just me?

Aug 29, 2026 5:09 AM in response to minecraftiaMACUser100

One of my posts was removed so some info might be missing. Not like they’re gonna tell me which one! They just gotta confuse things further..

terryb

Level 4

3,736 points

Aug 29, 2026 10:26 AM in response to joema

joema, thank you for consistently volunteering your deep, technical support to the FCP editing community. Your persistence and graceful patience are very much appreciated.

final cut pro 12.3 is failing to render to network shares