Is anyone using Projectserver with 2026+ on Mac Clients?

I need to sleep, thanks everyone for chiming in, still some ways to try to get this working.

night night brother
get some rest

at least on linux, we’ve been using v4 since day 1. And I would even think it is less prone to corruption since it is TCP based. My understanding is v3 is UDP. But macOS, no idea.

well screw me sideways, at least i can now say that

Linux client in fact only had issues reading the corrupted shit the mac was writing , if I set my timeline resizes with linux , they are there and happy and get saved and everything.

(both are running nfs v3 fwiw, ill try with V4 tomorrow)

who knew
random gibberish
awesome

its not the qnap, same thing now is happening on ubuntu /intel nuc with mac clients.

I can so far only make it happy by writing project data TO project server for whatever twisted af reason…

So something needs to be secretly different to the adsk projectserver - nfs , maybe its the underlying XFS vs ZFS vs EXT4 …

(also zero difference between nfs3 vs nfs4)

QNAP is worthless. I’ve run into so many issues with basic ass Linux stuff. I was using it as a 3rd backup, but turned it off a few months ago and haven’t thought about it till today.

3 Likes

I think ill actually give up and , idk do something else.

Got the new server, installed proejctserver on it, batch saves still take 5+ seconds, so it was never my VM that was slow - awesome.

thanks for all the fish, ill probably give up and move to resolve or idk, premiere - this is just not viable.

Have you tried saving a big Premiere file, even on fast local storage? When Premiere saves something it has to still write one giganto XML file. Only gets worse over time. There were times it could get so large, it would exceed your system’s memory and crash, and then you had to restore the backup from 2 weeks ago and redo all those edits.

We have a big project running on Resolve & Blackmagic Cloud (since early summer and continuing through April). Saves are anything but fast. I can start to load the project and make coffee and come back just in time to see the timelines.

This kind of stuff just doesn’t respond like a 7GB/s NVMe you got for X-Mas.

1 Like

Bloody Mary’s
165 degree view of the pacific edge of the western world
There are ways to make all of this work.
Alan can do it
I don’t do it that way.
Talking about it is tedious due to repetition.
Use resolve or nuke studio.
It’s quieter

1 Like

Something that @allklier mentioned reminded me of an issue I had…..

Some of our editors were convinced that having a small QNAP connected to Macs would be a brilliant ā€˜portable NAS solutionā€. We did some experiments using SSDs yet we had save times that were totally unacceptable. Premiere’s project format of XML was a poor combination of huge ascii text xml compressed with gz that didn’t help in the speed department. We also found that the NFS was a major slowdown between the Macs and the QNAP. Lots of mysterious pauses before, during and after saves.

Scarred by this, I’ve recently been using a similiar sized Synology (bug with with spinning disks) to two Flame 2026 on Macs and Premiere on Mac and Windows. In all cases, it’s been much faster than the QNAP was with SSDs. However, a big difference is that I’m using SMB with the Synology instead of NFS.

Since then I’ve always avoided QNAPs, but it made me think: could some of @finnjaeger’s issues be NFS-specific and would it be worth trying SMB for a test?

We recently had a discussion in this forum about SMB vs. NFS, and there are definitely considerations that may favor one or the other. In particular it may also depend on the version of NFS and SMB you’re using. Older implementations of NFS aren’t known for efficiency. And you could run it on TCP or UDP with their own tradeoffs again.

SMB has the downside that you don’t get UID management. You map all your permissions to a specific UID when you mount it, so that could be fine or a problem.

Now, SMB on Mac has it’s own issues since Apple nuked Samba and did their own. Most of the gremlins are gone, and I’m using SMB between the Mac and Linux for Flame w/o issue, and also SMB with the Synology. Several OS versions ago there would be problems where an SMB folder wouldn’t refresh and show you files you knew were there. But that hasn’t been an issue lately for me.

I have a 2018 Synology on 10GbE, shared with a Mac Studio and HP Linux Flame. All cross mounted with SMB and no issues whatsoever.

yea NFS is notoriously garbage on macOS

Flame does not support SMB for project storage.

I have absolutely 0 problems with the actual media read/writes its just my project home is on a nas so its shared between machines and that part is murding itself .

i am using SMB for media storage. (not for caches)

Does not support or does not work?

The one thing SMB trips over is the lack of soft and hard links. If Flame needs them for project and cache file, then this is a dead end.

does not work. doesnt even let you create a project on SMB due to what you just said.

btw this was gone for a hot minute and now showed back up on a project causing mayor issues in production flow.

I really dont know what to do anymore

Don’t use 2026 and revert to 2025?

2 Likes

What even is Pure Side Car Setup? Not doing any car project on fl26.
It’s fully reseting half of my resizes in 20 timelines all day. Exporting takes 3 times longer just because of quality checking just for this and reexporting nonstop.

1 Like

@hildebrandtbernd please get to our Support team and they will help you get back on your feet.

CaseNo:25190245.

i think my ticket got lost in the mids of new year or something with this same issue, its extremely hard to replicate and seems to happen when switching between machines on the same project server , not sure what is going on here

- my user account currently does not hold a flame license but bernds and some other of my users have a license so i cant really make new cases myself (I am just doing admin stuff no more hot seat for me at the moment) .

However this issue is very very annoying, would love to get to the bottom of this, otherwise we might need to roll back to 2025 which isnt really

possible… ugh .