My company’s IT restricts admin rights (I’m one of the lucky few who has them) and I work with them to deploy Pollination Grasshopper Plugin to the approved “Software Centre”.
The one issue I face with this is when updating LBT via the Versioner component, opening Rhino as admin and then running the versioner is successful, but then when I close and reopen Rhino normally (not admin) I get this error.
LBT Plugin: System.UnauthorizedAccessException: Access to the path 'C:\Program Files\ladybug_tools\grasshopper\dragonfly_grasshopper' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.AddSearchableDirsToStack(SearchData localSearchData)
at System.IO.FileSystemEnumerableIterator`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)
at System.Linq.Enumerable.<SelectManyIterator>d__17`2.MoveNext()
at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
at Ladybug.GH.Loader.Ladybug_LoaderInfo.LoadGrasshopperComponents()
at Ladybug.GH.Loader.Ladybug_LoaderInfo..ctor()
When I open Rhino as admin everything works fine.
Do you have any recommendations for how best to deal with this situation?
Thanks in advance,
Charlie
Edit
It seems like the issues continue once I open grasshopper as well
Snapshot of one of the component errors
Hi @charliebrooker - @chriswmackey and @mingbo are the ones to give you the better answer but from what I can see in the error message, it looks like the error is happening because the constructions subfolder under the Program Files installation is being removed when you use the LBT versioner. Can you check that manually and see if that is the case?
Here is the path: C:\Program Files\ladybug_tools\resources\standards\honeybee_energy_standards, and this is what it looks like on my machine.
Have you been able to replicate this error more than once when doing a fresh install and then running the Versioner? From the looks of the Grasshopper component message, it feels like the Versioner was somehow interrupted during the update process. So it would just be helpful to know if the error is replicate-able or if this might have resulted from a dropped internet connection at the wrong time or something like that.
Maybe @mingbo can tell us more by telling us what that .NET message means.
Opening the location @mostapha pointed to C:\Program Files\ladybug_tools\resources\standards\honeybee_energy_standards
Requires admin rights now (it didn’t before running Versioner, I checked after fresh install)
Entering admin rights, everything that should be there (to my eye) is there
Side note - I’m happy running a Pollination installer whenever anything gets updated, versioner would be convenient, especially when a new Pollination installer isn’t triggered for a specific update (e.g. for the automatic aperture groups going to 1.6.2, whereas the installer gives me 1.6.1)
It seems like the actual updating process is running correctly but all of the updated files now suddenly require Admin privileges to access them. Maybe there’s some issue in the way that the Ladybug.Executor is passing the Admin rights along to the pip install commands that are running under the hood of the LB Versioner. @mingbo is the author of the Executor that the Versioner uses to run the core library command with admin rights so he might be able to infer what is going on here.
@chriswmackey, am I right that you create the folders in the Python code? In that case, you might need to set the folder permissions in Python to make sure it is not only for the admin user. Admittedly, this is the first time that I see this to be an issue on Windows. It is a very common issue on Unix-based systems. This is the code that I use in queenbee-local to get around the issue.
def _change_permission(dst):
for root, dirs, files in os.walk(dst):
for d in dirs:
os.chmod(os.path.join(root, d), 0o777)
for f in files:
os.chmod(os.path.join(root, f), 0o777)
No, not exactly. Pip is creating the folders in all of the cases that @charliebrooker cites and not our Python code directly. Granted, I can usually guess what the folders will be after pip runs so I could still try to run that _change_permission function on the folders after pip completes. But it will be difficult in some cases to track all of the folders through the dependency tree to ensure that I change the permission of all of them.
Before trying to do something like that, should we see if changing the permission actually addresses @charliebrooker 's issue?
Charlie, could you try running the following Python code as admin and see if it enables you to load the Grasshopper components again when you are not running Rhino as admin?
import os
def _change_permission(dst):
for root, dirs, files in os.walk(dst):
for d in dirs:
os.chmod(os.path.join(root, d), 0o777)
for f in files:
os.chmod(os.path.join(root, f), 0o777)
master_dir = 'C:/Program Files/ladybug_tools/grasshopper'
sub_dirs = (
'ladybug_grasshopper', 'honeybee_grasshopper_core', 'honeybee_grasshopper_energy',
'honeybee_grasshopper_radiance', 'dragonfly_grasshopper'
)
for s_dir in sub_dirs:
comp_dir = os.path.join(master_dir, s_dir)
_change_permission(comp_dir)
I had a go at this earlier and was failing at the python part (I think I must’ve not added Python to PATH when I installed it and when I tried running through IDLE it didn’t seem to change the permissions - but I’d say it’s very likely I wasn’t running it correctly).
I went through manually quickly on all the folders and changed the permissions that way, which seems to have worked perfectly - components are now available in GH and of what I’ve tested seem to be working as expected.
At least now we have some idea of how to fix this but I still can’t understand why the process of running pip is removing the file permissions. Maybe it has to do with the fact that we are pip installing these particular problematic packages to a --target and so pip is treating them differently.
In addition to the Grasshopper components, did you also change the permissions on the folders at:
If the Grasshopper component folders and the honeybee_energy_standards folders were the only places that needed the permissions changed for you to get a fully-working installation, then I can say fairly confidently that it’s the pip install --target option that is causing the issue. In that case, I’ll implement a full fix if you confirm that this is the case.
Thanks, @charliebrooker . I haver put together a PR here with a fix that should address your issue:
I will merge it once you confirm that everything is working correctly after manually changing the file permissions on your end. The main thing that I want to be sure of is that you can successfully run an energy simulation with the “Model To OSM” component. If that is all good, then I’m pretty sure that the current fix is all that is needed.
Hi @chriswmackey, can confirm that “Model to OSM” works after changing those permissions.
I’m a little concerned that running that script didn’t seem to change the file permissions, (ran in command prompt as administrator, giving it the LBT python.exe and the code you’ve given as a .py file) although I’m sure that’s likely user error on my end in some form with limited Python knowledge.
@charliebrooker, we should have a new installer in the next few days. I will share it with you as soon as it is available so you can give it a try and see if it works as expected.
Awesome. I just merged the PR, @charliebrooker . Waiting for the installer might be the ideal way to test it but, if you’d like to test it now, you can do so with the following:
Run the LB Versioner and close Rhino.
Open Rhino as Admin and run the LB Versioner again.
After the second run, you should be able to open Rhino without Admin and everything should work if the fix I merged is good.
Hi @chriswmackey - I’ve just tried using the versioner on the Pollination 1.28.3 installer (from today) and still have the admin rights issue unfortunately, so you’re aware
Thanks for testing. Given this, I am not sure that there’s anything we can really do to help with this case since the current routine is definitely changing the file permissions here:
Is the message exactly the same as it was before?
Also, have you tried running the Versioner in Rhino as Admin and see if that makes a difference when you re-open Rhino not as Admin?
