Is anyone using Projectserver with 2026+ on Mac Clients?

I am having nothing but completely insane issues with failed links, i think it might be the way macs mount NFS shares, or whatever, chasing ghosts here, basically i cant save timeline resizes and getting a bunch of
Failed linking ‘h0037ad7f_6942eece_0008f929’ from ‘/Volumes/flameprojects26/reizetest_no_squash/.volatile_79789_501_20@1527B37B-01CB-4DCB-8954-A98F9A764ED8’ to ‘/Volumes/flameprojects26/reizetest_no_squash/catalog/Workspace.wksp/. workspace.wks_hist_TMP’

that .volatile tells me its NFS not able to do something its supposed to - right?

“flameprojects26” is on a QNAP nas , i tested, everything autodesk needs working like hardlinks, symlinks e.t.c and they all work however I stil get this broken mess ?

anyone has a idea if its just simply not supported with macOS clients to use a project server or am I doing something stupid?

the .volatile are not related to NFS specifically. They are basically how ADSK stores Batch Groups, BFX, temp stuff. It’s all insanity. But it is not an NFS error in and of itself.

But I would say, I would never use a Mac in a Flame studio wide deployment. The network issues are just too annoying. But your errors do seem NFS, permissions related.

1 Like

i have the same error trying from a linux client, no idea whats going on or why this has to be this stupid

what file system does the QNAP run?

I’ve also been telling ADSK that Flame writes out internal files in a strange way that in certain circumstances has massive performance penalties, for over a year.

the qnap is running ZFS

We run ZFS too, but as a bare metal RL10 server. What are you NFS export and mount options?

/Volumes/flameprojects26 from 192.168.10.206:/share/flameprojects26
– Original mount options:
General mount flags: 0x500018 nodev,nosuid,automounted,nobrowse
NFS parameters: resvport
File system locations:
/share/flameprojects26 @ 192.168.10.206 (192.168.10.206)
– Current mount parameters:
General mount flags: 0x4500018 nodev,nosuid,automounted,nobrowse,multilabel
NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,resvport,negnamecache,callumnt,locks,quota,rsize=32768,wsize=32768,readahead=16,dsize=32768,rdirplus,nodumbtimer,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,acrootdirmin=5,acrootdirmax=60,nomutejukebox,nonfc,sec=sys,accesscache=3
File system locations:
/share/flameprojects26 @ 192.168.10.206 (192.168.10.206)
Status flags: 0x0

above is mounted on the mac using the guide from adsk

and here is the NFS export from my qnap:

<world>(sync,wdelay,hide,no_subtree_check,fsid=cc9d8bd28259f34a6affedf3b2ca677b,sec=sys,rw,insecure,no_root_squash,no_all_squash)

This is what it should look like. And you are using NFSv3 which is shit old and crappy.

NAS:

[alan@nas02 ~]$ zfs get sharenfs vol02

NAME   PROPERTY  VALUE                               SOURCE

vol02  sharenfs  no_root_squash,rw,no_subtree_check  local

Workstation:

vol02 -rw,soft,nconnect=4 nas02-10:/mnt/vol02/active

nas02-10:/mnt/vol02/active/projects on /vol/projects type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,nconnect=4,timeo=600,retrans=2,sec=sys,clientaddr=192.168.10.104,local_lock=none,addr=192.168.10.12)

a lot of their documentation is very old and no longer applicable…. sometimes even wrong.

ADSK says I have to use NFS V3 on macOS. -.-

Man idk, I used the GUI to make a NFS share, thats just what the qnap is doing , if I keep the project data ON the project server instead everything is so god damn slow that I cant use flame anymore like at all.

like seriously, why cant flame just behave like a normal app the time I have wasted with this by now is so INSANE might as well finish in after effects and retire this bullshit

and the user IDs on the Mac, match the Qnap, which matches the Linux, which matches the DB server?

Flame on Mac is for undies guys, not studio guys.

2 Likes

No, why? are they supposed to? does that matter? what in the f.

mac uses some rando uid, idk project server also some uid and qnap yet another uid…

like honestlt it mounts the storage and has full read/write whatever

I wouldn’t attempt to do any of this without some time of central authentication… FreeIPA, ActiveDirectory, or some other horrendous solution.

1 Like

yea…. nope not going to happen .

will remove flame before I have to be doing that , honestly i do not have the capacity to deal with this

qnap doesnt even allow me to change uid of my user to 501 whic is what macOS uses, this is cursed.

central auth on macOS is such a PAIN IN THE ASS - ffs

I dont want user auth :frowning:

Honestly, yes you should abandon trying to use Flame in this way without central user authentication. This is what happens.

But at the very least, you could manually manage UIDs between all the different machines. But that is actually much more work than setting up proper user management.

2 Likes

adsk should write this as a requirement then and not let me loose my mind over it for weeks

2025 works fine, 2026 completelty does not work like this..

I don’t know…. Active Directory compatibility seems to be built in to macOS. We setup our studio Linux centric more than a decade ago using FreeIPA, so I have no experience with AD. And our Macs are basically side machines for internet stuff only. So we don’t have central auth on those.

I don’t see how 2025 would work either. In fact, there is a greater chance that the 2025 paradigm would be even more fucked than 2026.

2025 works perfectly fine with this setup, only difference is that project server itself holds the project data , so all the nfs mount stuff is handled by flame itself not a single weird thing with the project server :person_shrugging: can move between machines, its very solid

So the issue seems to maybe? be me trying to use the NFS share for project data, but again without it just saving a batch file takes 5 minutes

Yea definetely NFS related, if I use the project server as a location for the files its “fine” just slow as molasses