final cut pro 12.3 is failing to render to network shares

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.

What's actually happening: Your Apple Silicon Mac has a dedicated ProRes engine: hardware whose whole job is encoding video. Think of it as a machine with a fixed rack of trays, maybe a few dozen. Every frame it encodes sits on a tray, and a tray only comes back to the rack once that frame has been safely written into your export file. If writing to the file stops, trays stop coming back. The machine will wait about fifteen seconds for a free tray, then give up, and that "gave up" is the error you're seeing.

Why the writing stopped: When you export, FCP doesn't encode at the movie's playback speed. It goes as fast as the chip can, which is several times faster than real time. That's the massive upload spike you saw in Activity Monitor. All those frames pour across the network into the Mac Studio's memory, which acts like a bucket in front of its disks. For the first 15–30 seconds, everything flies, because you're really just filling the bucket. The problem is what's draining it: a 168 TB drive array that's 77% full, on a Studio that's simultaneously running Plex (which was hammering the CPU), Spotlight indexing, and a virtual machine.

When the bucket fills, the flow doesn't slow down, it stops dead until the Studio catches up. Stopped for more than ~15 seconds, and the encoder runs out of trays. That's why it always fails "in record time" right after the bandwidth spike: the crash lands exactly when the bucket fills.

Why a slow local drive never does this: A slow hard drive connected directly to your Mac slows you down like traffic: gradually and continuously, and macOS matches your export speed to it the whole way. The encoder handles slow just fine. But a network share under overload behaves like a drawbridge: full speed, then total stop. The encoder can't handle stopped. It's also why copying the same file in the Finder works; a copy will cheerfully wait a minute for the drawbridge; a video encoder won't.

And here's the kicker: your 10-gig network is part of the problem. A gigabit connection would have throttled the export to a speed the Studio could actually keep up with, and it probably would have finished. The fast pipe lets your laptop fill the Studio's bucket in seconds. Your cable, adapter, jumbo frames, and all the settings you tested are fine; this was never a network-quality problem.

If you need an immediate solution, export to your internal drive (or any local SSD), then copy the file over. That works every time, and the copy only costs a couple of minutes. If you want direct-to-share exports to survive, quiet the Studio first: pause Plex, turn off Spotlight indexing on the big media volumes, and don't keep a giant HFS+ array that full. But local-then-copy is what the pros do on FCP, Resolve and Premiere Pro, and this situation explains why.

The above information is based on spending several hours examining your logs, macOS framework code, and drawing on the 10 years I spent developing SQL Server at Microsoft.

We on this forum are only FCP end users like yourself. We volunteer to do this in our spare time. You are welcome to copy/paste and take the above verbatim description (which is likely the most elaborate investigation ever done on this issue) and discuss with Apple product support. You can also describe request Apple improve the product capability in this specific area by giving feedback here: Feedback - Final Cut Pro - Apple

Bruh, there's a Plex server running with heavy CPU usage. Also seems like a lot of old software installed on a production machine and it doesn't look like fresh OS install because there are things with install dates of 2023.

Disk related high CPU use shown with apfsd, spotlight, mds_stores and mdsync.

The Promise Utility crashed.

What was changed in sysctl.conf?

Configuration Files:

File /etc/sysctl.conf exists but not expected

You've got a crash in the VTDecoder process. In the past that was associated with Chrome and Google's auto updater software.

2026-08-22 18:01:34 VTDecoderXPCServiceZonto - Crash

Executable: /System/Library/Frameworks/VideoToolbox.framework/Versions/A/XPCServices/VTDecoderXPCServiceZonto.xpc/Contents/MacOS/VTDecoderXPCServiceZonto

If it were my facility I'd simplify to try to isolate where the problem is. Simple, small machine to machine transfers with no external drives or external NICs connected to see if results change. If no, I'd install a fresh OS on the Studio on an external SSD without migrating anything, boot from that and test.

Perhaps joema will chime in with his thoughts related to the VTDecoder crash.

(Just saw that you responded. Will update.)

OK I've finished studying your logs and other info. Comments:

• This is not a disk-space error. −536870181 is kIOReturnNoSpace — an IOKit driver code meaning "no space in my internal buffer." It came from the Apple silicon hardware ProRes encoder, whose ring of in-flight frames filled up and timed out because encoded frames stopped draining to disk.

• The frames stopped draining because writes to the SMB share stalled mid-export: the MacBook Pro pushes ProRes 422 HQ at close to 10 GbE line rate, and the Mac Studio — busy with Plex, Spotlight indexing, and a VM, writing to a 168 TB HFS+ array that is 77% full — could not absorb the burst. Once write latency exceeded the encoder driver's timeout, the export aborted.

Sequence of logged events:

• 09:35:37.8 Export begins: compression session CS/AFB created with codec apch (ProRes 422 HQ); the asset writer opens the destination file.
• ~09:35:40s Encoding runs hot — this is the "monstrous upload bandwidth" window. The encoder outruns real time; writes flood the SMB connection.
• 09:35:59.0 The hardware ProRes encoder gives up: "Timedout, could not find an empty spot" / "Could not get space in FrameInfoArray." This is the failure.
• 09:36:05.9 The failed frame propagates up: CMSampleBuffer error −12731, XPC transport error −16151.
• 09:36:06.0 Session invalidated: "encoded 589, dropped 0, duration 28207 ms." 589 frames made it in ~21 s of real encoding before the stall.
• 09:36:53 Writer finishes tearing down (an fsync to the share takes over a second); FCP posts the failure notification the user sees as error −536870181.

The failure mechanism

Everything in the export is a pipeline with backpressure. On Apple Silicon, the ProRes encoder is a hardware block with a fixed-size array of in-flight frame slots; a slot frees only when the encoded frame downstream of it is consumed. When the writer can't write, nothing frees, and after a fixed wait the driver times out.

Failure Sequence:

Hardware ProRes encoder (M4 Max)

encodes far faster than real time; holds each frame in FrameInfoArray until consumed

⬇︎

Asset writer in Final Cut Pro

appends encoded frames to TEST.mov on the share

⬇︎

SMB client → 10 GbE → Mac Studio

burst absorbed by caches at ~line rate at first; the bandwidth spike the user sees

⬇︎

Mac Studio write path — the stall

smbd flushing to a 168 TB HFS+ Pegasus array at 77% full, while Plex (90% CPU), Spotlight (mds_stores), apfsd, and a VM compete for the same machine — 36 GB RAM, 79 MB free

⬇︎

Backpressure reaches the encoder

writer blocks → frames stop draining → FrameInfoArray fills → timeout → kIOReturnNoSpace → "The share operation has failed"

This also explains the user-described failure signature: "both exports failed in record time, about 15–30 seconds after Activity Monitor detected the monstrous upload bandwidth". The first seconds run at cache speed; the failure lands exactly when the server's caches are full and true write latency is exposed. A Finder copy of the same file would survive, because a file copy tolerates long stalls. A real-time encoder pipeline has a timeout, and does not.

See following post for recommendations.

Yes, cache is persistent per library, stored in the library or as a sidecar file outside the library determined by FCP Settings config. Set storage locations in Final Cut Pro for Mac - Apple Support

To delete the cache, select the library in the browser, choose File->Delete Generated Library Files... Choose All Render files. Manage render files in Final Cut Pro for Mac - Apple Support 

If you're seeing this with a simple, SDR source file then it doesn't seem like it would be a cache problem, but easy to test.

Another easy thing to try is deleting FCP Prefs/Settings. Hold Option and Command while launching FCP and choose Delete Settings. It will open the default Untitled library. Re-open the library you were working on, configure the Settings back to the way you like them (disable Background rendering, etc.) and see if the issue has been resolved.

We use SMB NASes connected via 10GbE and haven't experienced export issues (other than the png issue on M4 Pro Mac Minis) but have never tried a SMB mounted DAS from another Mac. Something I've always been curious about.

A few questions:

How is the storage formatted?

How are you mounting the remote storage? AFP? SMB? NFS?

Are there large pngs in the timeline? There is an FCP bug that causes silent export failure when encountering pngs that are large or formatted in a particular way. It was discussed here recently.

Have you cleared the render cache?

Can you export a small, test project using the same network and storage pathways?

How is the storage formatted? Format storage devices for Final Cut Pro, Motion, and Compressor - Apple Support

I'm not clear on which machine has the OWC 10GbE adaptor and which has the (Thunderbolt 5?) DAS.

Are these failures correct?

Mac Mini OWC 10GbE --> Mac Studio builtin 10GbE with TB DAS. Fails

MBP builtin 10GbE --> Mac Studio builtin 10GbE with TB DAS. Fails

Have you tried short tests to simplify and narrow the search?

Mac Mini builtin 1GbE (not 10GbE) --> Mac Studio builtin 10GbE with TB DAS. Does this fail?

Mac Mini builtin 1GbE (not 10GbE) --> Mac Studio builtin 10GbE to internal SSD. Does this fail?

Also, just to rule it out, you've tried a different Cat6 cable, right?

There has been a profound miscommunication on this thread. The OP posted the client-side FCP export error, then Terry immediately asked for the Etrecheck output.

Since it's a client-side error, the OP post footer said "MacBook Pro (M4 Pro, 2024)," and nobody stated the macOS version on the client M4 Pro MacBook Pro, we assumed the Etrecheck was either from the machine having the errors, or the client machine was running the same version of macOS as given in Etrecheck.

It was not. Etrecheck was from the server machine. The client M4 MBP machine -- the one running FCP and the one encountering this error -- is running a beta version of macOS 27.

It's plausible that something like the above problem analysis may still apply. However, with beta software, all bets are off. All the labor and analysis on this problem have been on a beta version of macOS 27.

EVERYTHING has the 8GB thing. All Macs probably within a release time frame that I don’t know. All the recent ones I have. If you’re transferring from a Mac to another Mac over the network fast enough, you WILL run into it. It doesn’t happen with 1G connections probably because they aren’t fast enough to hit it.

I’ve probably used 25 different cables over the amount of time I’ve known this problem existed, across like 6 different machines.

In fact, sometimes my wifi in my office is so fast that I can hit the 8GB thing with no wires whatsoever.

The storage is formatted as HFS+, because it is very unwise to format it as APFS because it’s a bunch of spinning disks.. and I just don’t like APFS.

The OWC adapter is on the laptop, and the DAS is on the Studio. Moot because this is a problem with all Macs.

Basically what happens is that when I start a large transfer, of anything, from any 10G equipped Mac to any other 10G equipped Mac, there is network activity on both Macs, one upload, and one download, basically at line speed. Nothing else. There are no writes happening on the Mac that is being transferred TO. Weird, right? Doesn’t seem like that big of a problem, except that right when 8GB is reached, the transferring TO Mac finally starts writing as fast as it can to whatever drive you’re trying to transfer to. This completely HALTS the transfer until either 2 seconds passed if it’s an SSD you’re transferring to, or up to like 20 seconds if it’s any kind of HDD scheme. After that huge pause, it’ll continue transferring, but in my experience with HDDs/RAIDs the transfer speed gets knocked down to almost exactly half, because it’s still writing to the drives because it wasn’t when we started the transfer, so it’s panicking and trying to keep up and making the transfer speed miserable in the process. It can be even worse than this sometimes, and this basically makes anything to do with whatever drive you’re transferring to’s I/O performance almost 0 for anything else for the duration of the transfer after it hits the 8GB thing.

Now, Final Cut seems to have some random issue with latency, and if it can’t push the data fast enough or something, it just cancels the export entirely. REALLY stupid.

Given these 2 poor design choices or bugs, SOMETHING must be fixable..

That is what is going on, and it happens on every Mac that is fast enough on the network. Even off the network and just ethernetted directly from machine to machine, still happens. I’ve changed all of the options and settings for I/O on my Pegasus32s, and that’s moot anyway because it happens on every volume including the internal SSDs (though those are so fast that it plainly doesn’t matter). I’ve tried resetting Final Cut. I’ve tried consolidating the media in Final Cut (which works in a very dumb way). I’ve tried 3 different external 10G NICs. I even happens on my 2.5G NIC. Happens over WiFi, if it’s fast enough. Happens on old, handmedown installs migrated from older Mac, and it happens on brand new Macs with fresh installs. Go see for yourself, I guarantee you you will see this issue if you do any of this.

Thanks again, the work you did on this is very helpful. An initial study of these latest log files shows the underlying failure mechanism is the same, even though the error shown on the client might differ. Based on this new information, I'd describe the revised technical description as exhaustion of a finite slot pool during AVAssetWriter output to 10-gig Ethernet. The resultant timeouts are intentional defensive mechanisms. So that narrow aspect is by design. However, reaching that timeout during an otherwise supported export is not necessarily intended behavior.

I would also add that (based on your recent tests) it's looking less certain that a procedural workaround on the server would be reliable. It now seems less clear that freeing up disk space or reducing CPU activity on that machine would yield a dependable solution. I know you've said that before; I'm just saying the new data seems to agree with that.

To clarify, are you saying you saw this same problem, FCP export failure on 10-gig on Intel Macs, including those without hardware video acceleration such as the 2010 Mac Pro on High Sierra? That's just a curiosity question, since it seems to happen on numerous recent machines and macOS versions.

I may not have the hardware to test this until tomorrow. But I'm fairly confident that, based on your information, I'll be able to reproduce it. If so, I can make rapid progress by running it under various diagnostic tools to provide a high-quality, detailed bug report. Besides filing it with Apple, I will also file it on FCP.cafe, which will help with visibility.

Hi, this is guy that told him to post on here.

The source is ProRes 422 LT right now, and I'm trying to export it to ProRes 422 HQ. Both files are over the network, because it is extremely unwise to have as much storage as these 2 files require dangling off my laptop, nor do I actually have enough storage I can do that with.

The source is SDR, but my plan is to convert these SDR sources to HDR, export in the highest quality possible, and then process down in Compressor to a H265 HDR video file I can keep, so I can retain as much depth as possible, given the final codec I want to end up in.

There is nothing else in the timeline other than 1 video from 1 video file, no cuts or anything. This has been a consistent problem for me since 2021, I've just never been able to export using anything to do with the network, that being the destination, the source, or both.

I did what you said, the resetting of the Final Cut Pro settings, but instead of reopening the same library and clearing the cache, I just created a new library and a new project, and tested the export twice through that.

Both exports failed in record time, about 15-30 seconds after Activity Monitor detected the monstrous upload bandwidth usage.

This happens with all exports through the network, no matter what codec, framerate, bitrate, or container. The only thing that yields a success is a very short export, like a 4K60 video that's only a minute long. That would succeed after like 2 or 3 attempts. It also never fails at the same place twice, so it can't be a problematic frame or something.

My theory is that Final Cut Pro has a writeout limit for how long it allows it to need to write stuff before it quits for not being able to keep up. Macs seem to have this 8GB limit for writing to them over the network, every 8GB (if the transfer is fast enough) it will pause right in the middle of the transfer, then continue the transfer at GOD AWFUL speeds, then at some point reach the 8GB limit again, pause, and then resume. It's much worse on HDD based shares like the target shares for my renders, but it happens on SSDs as well. Only over the network.

And if you're wondering why I don't just try rendering to the SSDs (which are 4TB each) over the network until the export actually succeeds, it's because 3.5TB sometimes isn't enough. The largest export I've done, which is still smaller than my anticipated exports, was 8.5TB.

[Edited by Moderator]

Immediately after an export failure that produces the above-mentioned error, run this command in terminal to gather your macOS logs to a zip file, then send those to me at the below secure write-only link. I will analyze them. I have a lot of experience in this area.

Just copy/paste this command as written, press Enter, then enter your password. It will produce a zip file.

sudo -v; D=~/Desktop/FCPdiag_$(date +%Y%m%d_%H%M%S); mkdir -p "$D"; sudo log collect --last 15m --output "$D/fcp.logarchive"; { date; echo "=== df -H ==="; df -H; echo "=== purgeable / local snapshots ==="; tmutil listlocalsnapshots /; echo "=== diskutil list ==="; diskutil list; echo "=== TMPDIR ==="; echo "$TMPDIR"; df -H "$TMPDIR"; } > "$D/space.txt" 2>&1; ditto -c -k --sequesterRsrc --keepParent "$D" "$D.zip"; open -R "$D.zip"

I also need your system profile info. Run this, which takes a minute or so, and also send it:

system_profiler -xml -detailLevel full > ~/Desktop/SysProfile_$(date +%Y%m%d_%H%M%S).spx

https://we.tl/r-7QywANCg3hCU8K3H

What I need is some setting in some hidden file or something that tells SMB or whatever to write to storage immediately when it gets data in through the network, because that is the root cause of this crap.

I believe what joema showed is the Studio is attempting to write as fast as it can but the disk can't keep up and eventually the realtime encode cache can't drain and fails the process.

You can disable spotlight indexing (mds related activity) How to stop indexing? - Apple Community

joema, OP has said he experiences this behavior between *any* two Macs, even using internal storage, connected via 10GbE directory or through a switch, because he observes what appears to be a highwater of 8GB cached before any writing is attempted. My understanding of his description is this shows up as a pause during Finder copies while the cache is flushed to disk but a fail during FCP transcode exports because the destination Studio can't flush the existing cached 8GB fast enough to make room for new frames.

Yes, the framework call for this is AVAssetWriter. When encoding output via the media engine, the ProRes engine is a shared system resource. Various apps and utilities all use the same silicon. If, in the middle of a write, the "sink" (IOW network destination) suddenly hangs for more than a certain period, and if the driver permits the wait to continue, a single wedged app would deny the media engine to the whole machine.

It also cannot "time slice" away from that because the destination hung instantly in the middle of a hardware-accelerated write. So a hard fail is actually the best approach, vs trying to keep going and writing bad data, or sitting on the media engine, which would have other negative consequences. At least that's how I think it works.

I could run it under a debugger, look at more decompiled framework code, and dig up more details, but that would only provide more technical information about the behavior. My understanding, after spending several hours examining this at a low level, is that it's behaving as designed for this narrow case.

A review of similar Resolve and Premiere export cases on 10-gig networks suggests similar behavior and anomalies. However, Resolve has a final export throttle called "Render Speed." It is a producer-side rate limiter that limits the frame submission rate to AVAssetWriter. With that, you can blindly throttle back the export rate manually, but you have no idea how much is enough. It would vary with the destination volume's fluctuating load factor.