You might be right. The NAS I am saving to is 4 years older than the one that seems to work.
First, make sure your NAS firmware is up to date.
Over the past year, Windows has released some updates to block access to older network protocols, such as Samba 1.0 (considered insecure).
This has caused many problems with older operating systems and devices.
Therefore, something on your NAS may be preventing proper communication with Windows 11 and blocking file renaming or temporary file management.
Both Qnap NAS have the curent update firmware running. Just veriefied and compared settings.
Why should any NAS refuse to rename or replace a file while it allows ANY other program to do so?
That is not accurate, Rhino has itās own backup file processing system that is not handled by the OS. It also has an autosaving system. So there might be something with the timing of these operations on old NAS systems, I donāt know. You can maybe figure that out by running some sort of HDD speed analysis test that checks read and write speed + access speed. (Guessing here)
But now you know you need to use your NAS as a backup and the other one as a work drive.. 
I would not hold my breath for McNeel to fix anything relating old NASās.
Thereās no particular reasonā¦ but as you can see, one works and the other doesnātā¦ I have two Synologies and two servers, and neither has any problems saving/exporting Rhino filesā¦ so I donāt think itās your fault or McNeelās.
If the NAS has the same operating system (same firmware) as the one youāre using and all updates are installed, I recommend restoring it to factory settings to remove any configurations that may have been enabled accidentally.
As Holo said, working on a NAS that sometimes wonāt let you save your work isnāt reliable (maybe at some point it even decides to block access to saved files).
Have you asked QNAP support if theyāre aware of this issue?
If restoring doesnāt fix the problem, then youāll know youāve tried everythingā¦
I will not touch my NAS and scramble settings just for the sake of Rhino. I will simply save files locally or on different NAS or move there by backup. DonĀ“t worry. Why should I touch a running system with many PCs just for this. I hoped there is a simple setting in Rhino that has been changed since the last update. Oh well, just forget this. Thank you all for your help!
Because obviously something is wrong and itās not with Rhinoānone of this stuff is the responsibility of your software, Rhino does not ācareā where you are saving anything, thatās between your PC OS and your NASāRhino is just whatās illustrating it. That you have noticed. So far.
Youāre welcome!
Hi Walter,
Letās try and diagnose this with some facts. First question: Which OS does each of your NAS use? (QNAP offer choices, donāt assume that units from different eras are the same)
Are you silently stating in between posts and lines that this has not been a problem before updating to the latest version of Rhino 8? If so that changes the picture quite a bit.
Anyway, we are in the days of AIā¦
I dropped Claude the question and it suggests checking that SMB 2 or 3 are active on the QNAP.
Read the question and answer here:
Question
Hi, do you know how Rhino saves itās files and handles backups? A user states he has problems saving to a Qnap NAS, but only from Rhino and I wonder if can be due to how Rhino works on a temporary file and replaces the old only when the first temp is saved, and that this file renaming and handling can be too fast for what the NAS allows. There used to be some issues with Rhino saving to Dropbox folders back in the early days of cloud storage. What do you think?
Answer
Your instinct is spot on, and itās well documented in the Rhino community. Hereās a full breakdown:
How Rhino saves files
When a Rhino model is saved to a .3dm filename that already exists, the original is renamed to .3dmbak. Rhino But more importantly for your problem, Rhino uses a write-temp-then-rename pattern: it writes the new data to a temporary file first, then renames that temp file over the existing .3dm. This is a common safe-save pattern, but it means a successful save involves at minimum two filesystem operations on the target location ā a write and a rename/replace.
Rhino also creates lock files (<filename>.3dm.rhl) to let other instances of Rhino know that a file is in use. Rhino So during a save you can have temp files, lock files, the backup .3dmbak, and the final .3dm all being juggled in quick succession.
The known ātemporary file could not be renamedā error
This is a widely reported issue on the McNeel forums. The error message says the save failed because āthe temporary file could not be renamed.ā After this happens, trying to save again gives a read-only dialog, forcing the user to use Save As with a different file name. McNeel Forum
There are multiple threads going back through Rhino 6, 7, and 8 all hitting this same rename failure. McNeel Forum So yes ā the rename step is the fragile point, and itās exactly what you suspected.
Why a NAS (especially QNAP over SMB) makes this worse
Your analysis is very likely correct. The core issues are:
- SMB rename atomicity: The atomic ārename over existing fileā operation that Rhino relies on is well-supported on local NTFS, but SMB implementations ā particularly on NAS devices ā can handle this differently. QNAPās Samba layer may not support the same atomic replace semantics, causing the rename to either fail or take long enough that Rhino times out or sees a conflict.
- File locking over SMB: Using more than one protocol (like AFP and SMB simultaneously) on a NAS share can result in permission discrepancies and rename/delete failures. SMB locking behavior can itself cause issues with file operations. Studionetworksolutions Even with just SMB, QNAPās oplock (opportunistic locking) settings affect whether a client can perform atomic renames.
- QNAP firmware bugs with SMB file operations: There have been QNAP firmware bugs specifically around SMB file operations ā one firmware release noted a fix for āan issue where some users could not upload a file via SMB,ā and the problem returned with a later firmware version. QNAP NAS Community Forum This shows the SMB layer on QNAP is not always stable with file rename/replace operations.
The Dropbox parallel is very apt
The Dropbox problems youāre thinking of were the exact same mechanism ā Dropboxās sync agent would hold a file handle open or lock the file briefly while syncing, which interfered with the rename step. Rhinoās save would fail because it couldnāt atomically replace the existing file. A NAS over SMB can cause the same issue either through locking behavior, latency, or the NAS Samba layer not properly supporting the Windows MoveFileEx / MOVEFILE_REPLACE_EXISTING semantics.
What to try/recommend
- Check QNAP SMB settings: Ensure SMB2 or SMB3 is being used (not SMB1), and check oplock settings. Disabling opportunistic locking on the share can sometimes help with creative applications.
- Check QNAP firmware: Update to the latest firmware, as SMB-related bugs have been fixed in various releases.
- Disable the
.3dmbakbackup option in Rhino: In Options ā Files, disabling the automatic backup file creation removes one of the rename operations, which may reduce the chance of collision. - Avoid saving directly to the NAS during active work: Save locally and sync/copy to the NAS, much like the eventual recommendation for Dropbox was to save outside the sync folder.
- Check if the share has the Recycle Bin feature enabled on QNAP: This can intercept the deletion/rename of old files and add latency or cause errors.
The root cause is almost certainly Rhinoās temp-file-rename save pattern colliding with SMB file operation semantics on the QNAP. Itās not a Rhino bug per se, itās a mismatch between how Rhino expects atomic file replacement to work and what the NAS actually delivers.
One of the links Claude referred to was this thread:
Where this seems to have worked for Gianpietro:
Good luck, hope it helps, and keep on trusting your instincts.
Oh, wow! Will check all this.
My system is QTS 5.1.7.2770
Will take a while to read and figure out, but that seems to get closer.
And yes, an older version of Rhino worked/works well
Seems I found the problem.
I activated SMB settings on Qnap to āEnable Asynchronous I/Oā
Then created a new Rhino file, saved, changed something, saved again, made solid, exported stp sucessfully.
Rechecked earlier made file and exported stp sucessfully.
Step files look ok and can be used to print 3D as well.
So that is solved!
Excellent, and thanks for reporting back, thatās valuable for the forum.