We’re using a Qnap TVS-871T running 4.3.6.0776. Since 4.3.5 or so, we’ve noticed a peculiar bug involved with Final Cut Pro X and copying media.
First, the issue. When attempting to import media from a drive, be it one volume to another or a copy from the same drive into Final Cut, and the FCPX import preference is set to “Copy Media to Library”, media will remain half-copied, showing up blank in the timeline or browser. Upon investigating the file in Finder, the file will either: 1. Have a .fcpcopy extension added to the end, or 2. retains its name but hitting return to rename the file reveals a .fcpcopy extension. Upon removing the .fcpcopy extension in either case will result in the media becoming available again in Final Cut after a restart of the software. This behavior is exhibited both on audio and video, but seemingly not on still photos. It’s worth noting that if the FCPX import preference is set to “Leave Files in Place”, the media will behave correctly upon first import, but upon consolidation, it will also exhibit the same behavior as the “Copy Media to Library” setting.
We have dubbed this behavior “The Copy Bug” and it’s really interrupted our workflow. It also seems to affect timeline renders; any rendering that occurs will work at first and the render files will be present if the Library’s contents are explored in Finder, but upon FCPX restart, the timeline becomes unrendered. The files will remain in Finder, but any attempt to render again just adds new render files. It’s like it forgets. While we’re fortunate it’s not deleting our media or anything, it’s a nuisance that it happens every single time we drag footage into our projects. (This issue does not affect media imported from cards.
Next, some specs. We’ve noticed this behavior in both High Sierra and Mojave, so it doesn’t seem to be OS related but we understand it still might be. We’ve tested various versions of FCPX and it still occurs. We mount our Qnap raid using Qfinder’s particular Final Cut NFS format. One computer is connected directly via thunderbolt, 2 others are using thunderbolt to Ethernet adapters; the issue occurs regardless of connection. We believe the issue to exist somewhere in Qnap’s settings.
Interestingly, the issue does not seem to occur when mounting via SMB. However, this raises a new concern: FCPX libraries modified while on NFS will not open on an SMB mount, citing a permissions error. However a freshly created FCPX library will operate just fine in SMB.
Our question is twofold: what is causing this copy behavior to occur on NFS and how can we fix it, or alternatively, if we need to switch to SMB (which may be more beneficial in the long term), how do we prepare our media for the change from NFS to SMB?
I haven't had the time to talk to QNAP about it, no. I did find that copying the library to an external hard drive, and then copying back to the QNAP and opening via SMB seems to reset the permissions and solves the issue. A stopgap, if you will.
Are you importing your media into the FCPX library? or are you importing to an external folder?
When the media is managed inside the FCPX library bundle, We've noticed issues over NFS that are VERY similar to what you are mentioning. Try moving the media to outside the FCPX library if this is the case. This fixed the problem for us.
I'd be cautious moving over to the SMB, as you will loose the ability of fcpx to hard link when copying between libraries, which for our team is very useful.
Thanks FernKraft. I didn't realize that SMB didn't use Hard Links. For the work we do, they help significantly with saving storage space.
The external media option worked for us too - thanks for suggesting that. Still, it USED to work fine before about August of 2018. I might submit a ticket with QNAP to see what the deal is - if it's just our box or if it's something a QTS update did a few months back.