User cannot create a collection on GCSv5 managed server

[Andrew Reid]

Hi all --

I have a GCSv5 managed server I run at NIST, and have finally gotten to the point where I want a user to be able to create a new collection, but our first cut at this has failed.

After consenting to allow the Collections app to use his ID, as part of the collection creation dialog on the website, the user gets an error page, "Unable to load information from https://<hex>.dn.glob.us/api/v1/polcies". The hex string matches the first part of the server ID on the Globus page for the server endpoint, so what it's trying to do is reasonable.

I think I have the permissions set up correctly -- server endpoint is "public", the logged-in user can navigate to it, and start the "create a guest collection" dialog. There is a POSIX storage-manager connector on the server, with a domain restriction, and the user's Globus ID is linked to an e-mail address from that domain. Also, the user ID part of that e-mail address is a username on the system, and the passwd entry for that user is present on the main system and in the chroot. As a precaution, the globus-gridftp-manager service was restarted after this user was added, I'm not sure if that's really required.

I think this is the same workflow I've used previously to create test collections on the system, but in that case, there was potential confusion because I am also the admin on the endpoint, whereas in the failed attempt, the user is not an admin, but meets the requirements for collection creation otherwise.

What am I missing? 

     -- A.

--

Andrew Reid / andre...@nist.gov

[Stephen Rosen]

Hi Andrew,

When the collections app displays that error, it means that it attempted to call out to the endpoint over HTTPS to get information and failed.

Is it possible that you are on the same network as the endpoint, but your user is not?

If your firewall rules allow local HTTPS traffic, but not remote traffic, it's possible that you are able to succeed in creating collections but your user is not.

Users will need to be able to reach the endpoint on port 443 (TCP).

Another possible explanation is that the gcs_manager service might not be running on the endpoint or might be in a bad state.

You can restart the service with

   sudo systemctl restart gcs_manager.service

and see if that fixes it.

If neither of these explanations fits, it might be best to reach out to sup...@globus.org with more details (e.g. your endpoint ID) so that we can help you investigate.

Best regards,

-Stephen

[Andrew Reid]

That gcs_manager is a good guess, I don't think I restarted that after adding the user. 

However, it turns out it's not right, I rebooted the system today (by way of over-reaction), and it's still giving the same error.

Network and firewall explanations are unlikely, the user in question and I are on the same network at the same institution. It's not *impossible*, we're on different IPs, but it's not likely.

[Andrew Reid]

So for the benefit of people finding this in search or following along at home, I did follow up with support, and after exchanging clues, it now appears that this is an issue with the Microsoft Edge browser on Windows 10. It's unclear (to me) whether this is because of site-specific or user-specific settings we use at my agency for this browser, but a near-term solution was to retry the workflow in Chrome, where it worked.