Skip to content

[Scripts] 403 errors on Globus subgroup auto-creation #1402

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
theodore-s-beers opened this issue Apr 30, 2025 · 3 comments
Open

[Scripts] 403 errors on Globus subgroup auto-creation #1402

theodore-s-beers opened this issue Apr 30, 2025 · 3 comments
Labels
Component: Scripts Helper scripts or admin scripts

Comments

@theodore-s-beers
Copy link
Contributor

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 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?

Let me also tag @jagar2 and @xramsys here.

Acceptance Criteria

Any viable workaround would be sufficient, and most appreciated.

@JoshuaSBrown
Copy link
Collaborator

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 AronPerez changed the title 403 errors on Globus subgroup auto-creation [Scripts] 403 errors on Globus subgroup auto-creation Apr 30, 2025
@AronPerez AronPerez added the Component: Scripts Helper scripts or admin scripts label Apr 30, 2025
@theodore-s-beers
Copy link
Contributor Author

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.

@theodore-s-beers
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Scripts Helper scripts or admin scripts
Projects
None yet
Development

No branches or pull requests

3 participants