Saving Failure

Do you know what I can try to repeat this?

I tried using Hops within a huge definition, then later deleted the only instance of Hops which was within that same definition, but since then this file save error kept recurring until I uninstalled Hops.

Looking at my file directory I am seeing all of the leftover .3dm_tmp files referred to by the error messages and by previous posts.

Have you tried saving rhino files after using Grasshopper and Hops, then deleting Hops components and trying to save the Rhino file again?

What service release of Rhino are you using? I may need to use the exact same SR to repeat this bug.

Thanks for the info

Hi @Pascal,

I think you hit the point: saving to desktop (or any other local unit) does solve the problem.
Saving to my network unit (NAS) does present the same “read only” problem.

So I suppose it’s a problem with network units management: the strange thing is that, until one of the last Rhino updates (sorry don’t know which one) this wasn’t happening and (as I can remember) I didn’t recently do any change to my NAS access policies or so on.

What do you think?

This is the Rhino version installed:
Rhino 7 SR5 2021-3-9 (Rhino 7, 7.5.21068.13001, Git hash:master @ 76e41732e41ab44776e5ac3fa043f38d54440011)
License type: Commercial, build 2021-03-09
License details: Cloud Zoo

Windows 10.0.19042 SR0.0 or greater (Physical RAM: 64Gb)


I made some homework and I summarize here the results for you (together with the ones already seen):

    If I open a file with Rhino and then save it back with the same name in a LOCAL FOLDER - on any of the PCs in my network - there are no “read-only” problems.

    To double check I tried to reproduce the problem with some of the other softwares I commonly use (Affinity Publisher, The Gimp, Solid Edge): I opened a project file, an image, a dxf, etc. from one of my NAS folders (also from the very same folder Rhino files are in) and save them back with the same name. Result: any other software doesn’t have any sort of read-only problem and files are written without any hassle.

    From any PC (I have 4 ones) I try to save a file back in the NAS with the same name, Rhinoceros give back the same problem: read-only! Similarly, any other software, from any of these PCs, have no problem saving back its files with the same name and overwriting them, in any folder on the NAS.

    Until some weeks ago, there was no problem at all, saving back on the NAS with same name from Rhino 7.

    I tried to open a file from NAS with Rhino 7, save it back in Rhino 6 format with another name, then opened it with my previous Rhino 6 installation on the same machine, and save it back overwriting with same name: everything worked smoothly. No “read-only” messages. File just save over the same one on any NAS folder, from Rhino 6.
    Hope this helps to focus the problem

Have a good day.

. Gianpietro

PS: I don’t have Hops installed anywhere.

Rhino version 7.4.21067.13001, 2021-03-08

There’s another thing that may be at play here, in addition to Hops.

There’s a new advanced setting in 7.5 that attempts to speed up saving to network drives. I’m curious if disabling it change the read-only error? Here’s how:

  1. In Rhino, click Tools > Options
  2. In the Advanced tab, type WriteLocal in the Filter edit box.
  3. Clear the checkbox
  4. Click OK

Does this make any difference in leaving the files writable?



Disabling WriteLocal setting did the trick: now saving is possible again without read-only problems!
It was a really annoying trouble and I was definitely getting mad.

Thank you @brian !

Glad this is working for you, but this also means we need to fix a critical bug in this area before shipping the next service release of Rhino. Can you run SystemInfo and post the results here? I want to try and get a better understand of what makes your Rhino behave different than mine.

Hi @stevebaer

I’m sorry this means more work: on the other side it’s a good thing we finally focused the thing a little better.

I post here my SystemInfo but consider that this “bug” happens on four different PCs in my studio. All different in hardware configuration: common things are, apart for the network and the NAS they access, the versions of Win10 and Rhino 7 RCs installed (the last one available, the same for all the PCs).
By the way: on this desktop, the video drivers have been downgraded to older ones (this morning!) due to system stability issues related to the newer ones. But also with the newest video drivers, problem with saving from Rhino was exactly the same.

Here is the data you asked for:

Rhino 7 SR5 2021-3-9 (Rhino 7, 7.5.21068.13001, Git hash:master @ 76e41732e41ab44776e5ac3fa043f38d54440011)
License type: Commerciale, build 2021-03-09
License details: Cloud Zoo

Windows 10.0.19042 SR0.0 or greater (Physical RAM: 64Gb)

Computer platform: DESKTOP 

Standard graphics configuration.
  Primary display and OpenGL: NVIDIA Quadro 4000 (NVidia) Memory: 2GB, Driver date: 7-22-2015 (M-D-Y). OpenGL Ver: 4.5.0 NVIDIA 353.62
    > Accelerated graphics device with 2 adapter port(s)
        - Windows Main Display attached to adapter port #0
        - Secondary monitor attached to adapter port #1

OpenGL Settings
  Safe mode: Off
  Use accelerated hardware modes: On
  Redraw scene when viewports are exposed: On
  Anti-alias mode: 8x
  Mip Map Filtering: Linear
  Anisotropic Filtering Mode: High
  Vendor Name: NVIDIA Corporation
  Render version: 4.5
  Shading Language: 4.50 NVIDIA
  Driver Date: 7-22-2015
  Driver Version:
  Maximum Texture size: 16384 x 16384
  Z-Buffer depth: 24 bits
  Maximum Viewport size: 16384 x 16384
  Total Video Memory: 2 GB

Rhino plugins that do not ship with Rhino
  C:\Program Files\Common Files\McNeel\Rhinoceros\7.0\Plug-ins\Iris (1cd9c8f5-c901-426c-8e80-d6a2e2b18bba)\1.0.7284.18297\Iris.WinR6.rhp	"Iris"

Rhino plugins that ship with Rhino
  C:\Program Files\Rhino WIP\Plug-ins\Commands.rhp	"Commands"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\WebBrowser.rhp	"WebBrowser"	
  C:\Program Files\Rhino WIP\Plug-ins\rdk.rhp	"Renderer Development Kit"	
  C:\Program Files\Rhino WIP\Plug-ins\RhinoScript.rhp	"RhinoScript"	
  C:\Program Files\Rhino WIP\Plug-ins\IdleProcessor.rhp	"IdleProcessor"	
  C:\Program Files\Rhino WIP\Plug-ins\RhinoRenderCycles.rhp	"Rhino Render"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\rdk_etoui.rhp	"RDK_EtoUI"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\rdk_ui.rhp	"Renderer Development Kit UI"	
  C:\Program Files\Rhino WIP\Plug-ins\NamedSnapshots.rhp	"Snapshots"	
  C:\Program Files\Rhino WIP\Plug-ins\Alerter.rhp	"Alerter"	
  C:\Program Files\Rhino WIP\Plug-ins\RhinoCycles.rhp	"RhinoCycles"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\Grasshopper\GrasshopperPlugin.rhp	"Grasshopper"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\Toolbars\Toolbars.rhp	"Toolbars"	7.5.21068.13001
  C:\Program Files\Rhino WIP\Plug-ins\3dxrhino.rhp	"3Dconnexion 3D Mouse"	
  C:\Program Files\Rhino WIP\Plug-ins\Displacement.rhp	"Displacement"

Hope this helps.


. Gianpietro

Thanks for the systeminfo. Nothing looks out of place so something else must be going on. I will probably have more questions as I dig into this. I really want this feature to work for your system as in general it makes saving to network drives much faster.


Looks like a problem of setting the rights when writing the file. I can tell you something additional immediately, as you are interested. A really strange behaviour in the folder/files:

When you try to save <filename>.3dm overwriting it and the two alerts are popping up, then the file is not saved at all.

But if you go in the folder you find that also the original file and the “working” one, they don’t exist anymore: <filename>.3dm was appearently re-named and SAVED as <filename>.3dmbak AND the file <filename>.3dm.rhl disappeared.

This is very strange as that means that Rhino DOES HAVE the right to write on that network folder.

@stevebaer I had chance to try what you suggested

here are the very exact steps I have followed (I don’t currently have Hops installed, and Rhino 7 is fully updated to last release candidate)

I have downloaded Process Explorer like suggested by @brian , so you will see on the screenshots also those file handling info

→ on Rhino I created a dummy file and saved it on C:\users\me\desktop and on D:
→ installed Hops via PackageManager
→ reboot

→ start Rhino and open file on desktop: I can save, no problems (I didn’t have problems yesterday either, as long as GH was not involved)

→ same Rhino instance, now I also open GH
→ as soon as GH starts, my firewall tells me this (sorry it’s in Italian… “first connection attempted by compute.geometry.exe” I let it go through my firewall)

→ I click the Save button: same error pops up, like yesterday

that error windows is followed by a smaller error window like yesterday (I copy and paste yesterday’s one, I did not screenshot it, anyway it’s same text, just pointing to the file on C:.…\Desktop

from the command line you can see the exact events:

as soon as GH was opened (I didn’t even touch the GH canvas) the file was in read-only mode for Rhino, and was handled by compute.geometry.exe instead of Rhino.exe

exactly the same behavior for the Rhino file saved on my D:\ drive
here I starty Rhino and open my dummy-file on D:, click save, and the file is saved, no errors, file is handled by Rhino.exe

as soon as I launch GH and click the save icon:

hope this helps!

Hi @inno ,

did you try what @brian suggested to me? Just to understand if the thing works also in your installation. I quote his post here:

With me it worked like a charm. Let me know.
Ciao e buona serata!

. Gianpietro

thanks @gian , I gave it a try

but unluckily it does not solve the issue in my case

Rhino dummy file on desktop:

Rhino dummy file on D drive:


Two different issues then…

Yes, I do think there are two different issues here. Thanks @gian and @inno for the detailed descriptions of what you are experiencing. This really helps me figure out where to begin looking for the bugs.

I’m focusing on both of these bugs right now as they are very important to get fixed right away.


Hi @stevebaer

I’m happy when I can help.
But, first of all, you helped me, so: many thanks to you, @brian and @pascal for the great work you make and for the great support you give. And, of course, thank you for the workaround.

One last thing: please, if you can, keep me informed on the solution of this issue, writing in this thread a brief comment once finished or just posting now the link to the bug so I can follow the discussion.

Just curious… :slight_smile:

Have a nice day everybody!

. Gianpietro

@inno and @LeoPedersen I was able to track down and fix the file saving issue when Hops is installed. I just published a new version of Hops (0.4.6) to the package manager that fixes the issue you were seeing. Thanks for all of the help so I could find the bug.

@gian the network saving issue that you are seeing is unrelated. We have been able to repeat what you are seeing and are still working on the issue.

Thanks everyone


it works perfectly indeed :+1: thanks so much!!