You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are in the process of updating, and effectively redeploying, one of our DataFed repositories. This involves going through the Globus auth process via the generate_globus_files.sh script (link to file). That in turn calls a Python script, initialize_globus_endpoint.py (link to file). And we have been encountering repeated failures at this point, with Globus returning 403 errors relating to permissions around group creation.
To be more specific, the Python script in question imports GroupsClient from globus_sdk. It then instantiates a client with the variable name gr_rt. Later, if the group that is needed for the DataFed endpoint does not already exist—which is the situation in which we find ourselves, since we're basically doing a fresh redeployment—then gr_rt.create_group is called. This is precisely where we hit a wall, with Globus returning 403.
The error message that we see is as follows: "You must be the admin of the parent to create a child group." If I understand correctly, the parent group is the group associated with our institutional Globus subscription. Does this mean that only an admin of the subscription group can deploy a DataFed repository linked to that subscription?
There are concerns at our institution about Globus administrative privileges. It is easy to imagine, for example, a university in which multiple research groups might have their own DataFed repositories, but it would not be feasible for the PI of every group to have administrative control over the university's Globus subscription. Presumably there are ways of dealing with this, and we just haven't found them yet. Is anyone on the DataFed side familiar with workarounds? It would be ideal if the parent group of the DataFed repository group could itself be a child of the Globus subscription group. Does that make sense?
The generate_globus_files.sh file, is a convenience script that will log you in and create a globus client with permissions, to create and setup a globus connect server. You can definately do all the things in the script through the Globus web UI. Let me see if I can compile a list of steps for you and we can work on getting them documented.
AronPerez
changed the title
403 errors on Globus subgroup auto-creation
[Scripts] 403 errors on Globus subgroup auto-creation
Apr 30, 2025
You can definitely do all the things in the script through the Globus web UI.
That's a good idea in itself. We might get a different perspective on exactly where the failure is occurring if we go through the group creation process manually in the web app.
Note: we were able to find a workaround for the specific repository that we were struggling with in this instance. But I'm inclined to leave this issue open, since it seems likely that we will run into the same problem in the future—and research groups at other institutions may, as well.
Description
We are in the process of updating, and effectively redeploying, one of our DataFed repositories. This involves going through the Globus auth process via the
generate_globus_files.sh
script (link to file). That in turn calls a Python script,initialize_globus_endpoint.py
(link to file). And we have been encountering repeated failures at this point, with Globus returning 403 errors relating to permissions around group creation.To be more specific, the Python script in question imports
GroupsClient
fromglobus_sdk
. It then instantiates a client with the variable namegr_rt
. Later, if the group that is needed for the DataFed endpoint does not already exist—which is the situation in which we find ourselves, since we're basically doing a fresh redeployment—thengr_rt.create_group
is called. This is precisely where we hit a wall, with Globus returning 403.The error message that we see is as follows: "You must be the admin of the parent to create a child group." If I understand correctly, the parent group is the group associated with our institutional Globus subscription. Does this mean that only an admin of the subscription group can deploy a DataFed repository linked to that subscription?
There are concerns at our institution about Globus administrative privileges. It is easy to imagine, for example, a university in which multiple research groups might have their own DataFed repositories, but it would not be feasible for the PI of every group to have administrative control over the university's Globus subscription. Presumably there are ways of dealing with this, and we just haven't found them yet. Is anyone on the DataFed side familiar with workarounds? It would be ideal if the parent group of the DataFed repository group could itself be a child of the Globus subscription group. Does that make sense?
Let me also tag @jagar2 and @xramsys here.
Acceptance Criteria
Any viable workaround would be sufficient, and most appreciated.
The text was updated successfully, but these errors were encountered: