Going to try this today, thanks.
Ah, fascinating. So we know which io command causes the issue and it is totally optional with acceptable tradeoffs.
Where there is a will, there is a way……
May there be more will….
Out of curiosity, if you google file locking and SMB, you will find lots of articles about the vagaries of Samba (the industry norm implementation, used on most NAS devices).
There are different configuration parameters on how to handle locking etc. In fact if you look in the ‘File Services’ config panel on Synology and go to ‘Advanced’ there are number of options to pick from.
Which makes me think, the fact that some have experienced that but not all, may have to do with how these options are set to find the right combination that makes Flame archive happy.
It may also explain some of the differences between Linux and Mac, as Apple a few OS versions ago abandoned Samba for their own home-grown implementation of SMB, which had anything but a smooth roll-out.
Not easy to find the answer here without a system exhibiting the problem. It seems for now the secret switch mentioned above gets around the I/O command that gets tripped by different locking configurations.
Just because something is standard doesn’t make it good. I have run into file locking and directory locking issues with a few differnt NAS implementations. It’s annoying and has made me grown bitter with SMB over the years. NFS may take more work, but has given me less issues once set up.
2 Likes
That could be said about a lot of things considered ‘Standard’. A few candidates come to mind 
If you have the time and capability of setting up NFS, it’s definitely superior. And if you have an IT department that takes care of it, super simple. It also requires a more unified user id management across all your systems.
But for 1 or 2 person shops, like a number of us are, it’s yet another IT task that could be optional and not billable. If your Synology/QNap NAS works fine in this environment, why force it? Give people the option.
And as I mentioned above, it’s not just the NAS, but also shares from other other systems you may have to move files back and forth. ADSK has an instruction page on how to enable NFS server functionality on Mac OS. There is no such thing for Win10 though. You have to find some 3rd party solution.
And before too long you spend more than an hour sorting this out.
And it creates additional adoption barriers. Folks complain that there’s not as much fresh blood on Flame. The easier you make it for people to succeed with it, the more likely they will use it.
I grew up with NFS in 90s. There was no SMB back then. Those were the days for Novell Netware for Windows. But most young artists will never have heard of NFS. Yet they may have to archive their Flame project and might just own a small Synology NAS, which is a smart move to have two independent storage devices. Well, I guess they probably would also use a Mac for the most part, and it doesn’t seem to be broken on a Mac, though equally unsupported.
Correction: Looked it up. SMB originated on OS/2 in '83, was first implement on Windows in NT3.1, with SMB 1 goes back to '96. But I don’t recall ever using it for file sharing back then. It was Novell or NFS. Gosh, we’re aging fast.
This worked a treat, thanks. That said, we subsequently decided to move over to nfs4… I’ve never felt so good deleting a quicktime before.
NFS feels slower though, 100mb/s archive write compared to 300mb/s we had but hey.
1 Like
So for what’s it worth as a pure data point…
I just setup a different Linux Flame on a Dell 7820. As a non-production system to do some other tests.
Installed Rocky 8.7 ISO, DKU 19.1, Flame 2025.1.1, all plain vanilla.
- I had no problems with my Autodesk Login license to run Flame. At least so far. Let’s see if stays that way.
- I have mounted my Synology NAS via SMB, restored another project from archive, did some renders, and re-archived it back to the NAS via SMB, using 2 segments. No errors, no issues.
The problems discussed here are most definitely real. But they’re also more nuanced. There are other variables at play. Which is why it’s important to work through those with ADSK support, and where it’s less helpful if they say ‘you’re on you’re own’.
1 Like
@allklier - great community contribution brother - thank you
I’m curious if your results are the same in 9.3, but am in no way advocating for you to waste another 1 hour+.
Ha, I already wasted hours on 9.3 on my other system with the finicky NVidia drivers. My regular system has an A5000, this one only has on older RTX4000.
I don’t think I’m touching 9.3 until we get to 2026. Only so many gremlins I’ll put up with.
fair
It is possible but not supported officially. Since it is a protocol not validated by the Flame Development team to be used directly in archiving or framestore volumes, you could find the way to workaround some specific issues, but eventually it could cause unexpected errors in files locking, users mapping, etc.
Additionally smb servers have quite a lot of different configs and options dependent on the server side that could not be troubleshooted from the client side.
Most of the NAS appliances have both the SMB and NFS options available to be enabled at the same time.
A windows share is not really a good idea for mounting a framestore volume or an archive repository, for sure, but nothing prevents to mount any windows share in Mac os windows if you are using it to access some files for importing or transfering.
In any case, I would suggest all of you to fill a feature request in the feedback.autodesk.com site for the Flame Product Team to be aware of the interest in the SMB protocol certification.
Thank you @AbrahamLevi for that perspective.
It’s good to distinguish between
- Framestore Storage
- Archive Storage
- General Storage (footage, gfx assets, etc)
It makes sense to hold Framestore Storage to the highest standard, which SMB may not meet.
I think where we diverged is Archive Storage. A lot of folks maintain job archives on NAS devices, which may include Flame archives as part of them. So it seems a natural thing to archive a job to a NAS devices (which often defaults to SMB, but can use NFS) during or after a job has wrapped.
It is easier to support NFS from a NAS than from another workstation.
And yes, there are a lot of variables. It would be ok to restrict SMB support to specific conditions (as I outlined in the improvement request).
Improvement Request FL-03365
While writing this, I also came across a related, but different SMB issue: FS_03171 which relates to the inability to delete files when SMB volumes are used as render destinations.
1 Like
Thanks to you for such a constructive perspective!! Sometimes it looks like things are not being taking in account and that is not true. The drawbacks are not really well calibrated frequently.
5 Likes
In our family we have a mantra:
“Don’t Bitch without a Pitch”
Translating for non-native English speakers: Don’t complain if you don’t want to be part of the solution.
3 Likes
Complain once. Then either join the beta or fill out a feature request.
2 Likes
Check and check. Can I know complain about something else? 
2 Likes
And as if by magic German money pours in to help develop Samba
1 Like