So with 2025.1 I haven’t been able to archive to my NAS. My guy spent a lot of time and finally found some buried ADSK article of the problem. He had to switch it from Samba to NFS. It’s now archiving fine. Anyone else seen this?
Here is the article.
That seems weird and concerning, but not entirely accurate.
I run 2025 on Rocky 8.7 and I can archive to my SMB mounted Synology without issues.
Having to switch to NFS would be a headache and not even solve all the problems. While many NAS units support NFS, we also frequently cross mount local drives other Mac or Windows systems, generally via the SMB stack and that works perfectly fine.
The article seems to describe a particular problem with the lock file Flame wants to create. So this may apply to specific smb stacks and NAS products, but may not be a universal problem.
Love how ADSK is washing its hands from the single most universal network drive protocol ‘not supported’. Getting your Mac or Windows system to be a NFS server would be an even bigger headache.
In a world where not every Flame install is in a big studio environment anymore, they need to relax a bit more. I know it’s been a hurdle for everyone coming off carefully tuned turnkey solutions. But that’s the reality today.
But lets not have the whole freesync debate all over again.
PS: Wonder if this is merely a matter of the ISO. I don’t think it installs the cifs-utils package by default, so mounting the NAS won’t work until you do that.
dnf install cifs-utils
Should take care of this.
We archive to a SMB mounted NAS constantly with no issues. I know that’s not particularly helpful beyond letting you know that it is possible.
Yep, looks like we have the same issue. Just checked in on a 2025.1.1 archive i set off last night & it’s sitting there having written 1 segment & complaining about the ‘Archive-lock: no such file or directory.’
I guess we’re going to have to go back to 2024.2 which worked fine
Ugh. There are some fantastic features in 2025.1, but it seems to be let down by infrastructure shortcomings.
Might try to install it on a backup Linux system so I can eval better.
Sorry it’s hit you too, Tim. But I’m glad to know I’m not either incompetent or delusional or both.
Have logged a ticket with Adsk. Will update here if I hear anything.
Looks like it only happens after an archive segment is full & it needs to start the next one. If i make the set the segment size to 300gb rather than 25gb i can squeeze it into a single seg & it’s done. Will test more in Monday.
That’s a great find. Thanks, Tim.
However, losing a segment of that size would be devastating, as opposed to smaller segment sizes.
yup… this is super dangerous not great practice.
I wonder as a better work around, if you just create a bunch of blank stub files so it doesn’t need to try and create them, just write to them.
touch archive.001 archive.002…etc
super lame, but safer.
Since we’re now in the area of educated guesses…
The article above (which could be related, but we’re not certain) references the lock file, rather than the segment file.
It’s common for various processes that use multiple files to create some 0-byte file (often named xyz.lck) as a semaphore to avoid multiple processes accessing the same files simultaneously.
You certainly would do that in a multi-segment archive, as you want to make sure you only have one Flame having the archive open at the same time. Probably happens as it prompts you if you want it open for read-only or read-write.
It’s conceivable, that Flame skips that lock file on the first segment, since the fact that there is only one segment reduces conflict. That could explain why it works on 1 segment archives, but not multi-segment archives.
And then why the lock file gets permissions problems… Well, NFS has an elaborate way of mapping user names/ids, between the client and the server, and you can actually have each user on Linux access the NAS with his/her specific user id.
SMB/CIFS has no such thing. When you mount an SMB filesystem on Linux, as part of the mount command you specify the user id and group on Linux to use which is then mapped to the user ID of your login/password you authenticated with during mounting the file system. It’s much more barebones.
Now it could be that the Flame archive process doesn’t run with your user id, but some other system user id on Linux (I haven’t check, but conceivable). It’s possible that this messes up the permissions mapping, and why the Flame process gets an error when it tries to create the lock file.
Anyway - a plausible educated scenario… But only real debugging will tell the truth. You’d have to look at the process list while a longer archive is running to see which user the archive runs at. Could also depend on how you mounted your SMB shares.
@allklier - If you are archiving from the UI then you are using your current flame user and the GID of the project.
If you archive from the command line you can indeed masquerade as a different user and group.
The umask settings will affect these choices too.
as expected, Adsk response just in…
‘SMB is not a supported file system to archive for Flame since it is not POSIX compliant.’
thanks
Very disappointing. That is a view to a time gone by, not the reality quite a few of us have today.
Future of Flame may depend not only if we can attract and train juniors (as often debated) but also if Flame can evolve with the environment.
The one other app that shares this attitude is Baselight, and it has had an uphill battle for that reason.
Since NFS is not really easy for most smaller setups, the simple answer is - make archive on some local disk, then copy. Linux is more than happy to talk to an SMB mounted volume.
It’s cheaper to buy another disk then to setup NFS in your environment if you don’t already use it.
When the parents are prickly, sometimes you just have to ignore them and find your own way. Then when you’re in your adult life and sit at the family dinner looking back you can all have a laugh about it.
FWIW I just archived 360 gig in 10gig chunks to my synology server via smb. 2025.1
interesting. is that a mac maybe? we’re not getting this ‘feature’ on mac-studio, just the z8’s
Sorry yes. I have a mac studio. Didnt realise the issue is with linux
This isn’t unique to Flame 2025.1.1.
We had a similar problem raise its ugly head with a few of our machines running Flame 2023.3.1
Sep 10 15:28:05 : PID 2314370: Cannot set lock "/Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive_03/BJ0000_dummy_job_Archive_03-lock" - Operation not supported
Sep 10 15:28:05 : Could not read lock file: Could not read /Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive_03/BJ0000_dummy_job_Archive_03-lock: No such file or directory
Sep 10 15:29:07 : PID 2314370: Cannot set lock "/Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive_02-lock" - Operation not supported
Sep 10 15:29:07 : Could not read lock file: Could not read /Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive_02-lock: No such file or directory
Sep 10 15:30:00 : PID 2314370: Cannot set lock "/Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive/BJ0000_dummy_job_Archive-lock" - Operation not supported
Sep 10 15:30:00 : Could not read lock file: Could not read /Volumes/beast/BJ0000_dummy_job/archive/BJ0000_dummy_job_Archive/BJ0000_dummy_job_Archive-lock: No such file or directory
Support told us that SMB wasn’t supported and that we needed to change our server to NFS 
But then they came back with a possible solution:
As a workaround, you may add these lines in your /opt/Autodesk/flame_/bin/startApplication
os.environ['DL_ARCH_FILE_NO_DIRECT_IO'] = '1' os.environ['DL_DISABLE_DIRECT'] = 'true'
To avoid this behavior, perform the following as the root user:
This solved our problem on Flame 2023.3.1. and I have just added this to my Flame 2025.1.1 test machine and it has enabled me to archive.
I hope this helps others 