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?
This issue has come up again for us for a couple of reasons - one being the original reason I posted about impacting someone else. Let me know if there’s anything we can do to test.
The second reason is a bit more tangential, we’ve noticed that the following folders (measures, standards) are only added to the user that installs Pollination, which has caused some problems with shared analysis PCs. It seems that parts of the code need these folders / contents.
I tried looking more into the original issue and it’s possible that the reason why the fix I implemented earlier did not work is that this permission issue seems to be specific to Windows machines and the method we were using to change the permissions is more general and not specific to Windows. I see that someone has posted a possible way to grant access to the folder via command line here:
If you are able to confirm that you’re able to change the permission from command line without needing to manually change the folder permission like you currently do, then I can integrate this command into what is running with the Versioner. So you’d essentially try something like this and a command prompt run as admin:
TAKEOWN /F "C:\Program Files\ladybug_tools\grasshopper" /R /D Y
If that works, let me know and I will have a go at integrating it into the Versioner.
The other issue that you cite about the user-specific folders only being created for the user who runs the installer is a separate matter. I think @mingbo has implemented something that will automatically create those folders for the current user whenever that user opens Pollination Rhino (since we have a setup-resources command in the Python libraries that does this). If opening Pollination Rhino does not create the folders for the user, then please open a different discussion topic for it here on Discourse and we’ll try to get it addressed.
I’ve also been having the same issues as Charlie with certain folders requiring admin unblocking after running the versioner.
I ran both command promts you suggested, but still faced the same issues. The error message I faced when opening grasshopper for the first time after running your promts is below.
Just to confirm, you were running the command prompt as admin, correct?
I would like to implement a solution here but it’s just hard for me to test this on my end since the issue seems to be specific to the admin group policy. If you find a way to grant permission to those folders via command line instead of with the “Continue” button on the “You don’t currently have permission to access this folder” window that @charliebrooker posted, then post the command line workflow here and I will try integrating it into the process that the Versioner runs.
I think that’s the best I can offer given that I can’t quite figure out how the permission is blocked in the first place.
