But you're not using the webserver, you're sending the cURL requests manually, aren't you?

Thanks a lot! I’ ll replace credentials with new user in assigned to a new company ID to call users.get_all again.

What server are you using? a locally-installed server?

These values are overridden in the k8s deployment. See https://github.com/allegroai/clearml-server-k8s/blob/master/clearml-server-cloud-ready/templates/secrets.yaml

OK, so the company you're referring to is encoded in the authorization header

Oh, wait

the webserver secret isn't there

Are you sending these requests manually?
COK. In any case, you should be looking at the

I send them with curl.

Just the apiserver

Oh, you're just debugging?

<webserver>/api is a reverse proxy

I have another question. Does the following apis in the picture are served by both of apiserver and webserver, or just one of them ?

The chart might be replacing that

Hi FloppyDeer99 ,
the users.get_all should be sent to the apiserver, not to the webserver. In any case, the header will not affect this request as the server will be using your user's identity (encoded in the authorization header) to resolve the company

In any case the user associated with the credentials you use is not assigned to the same cinoany ID you replaced

More in detail?

Are you sending these requests manually?
OK. In any case, you should be looking at the

How can I fresh DB? Mongo or Redis?

where did you get it from?

But you’re not using the webserver, you’re sending the cURL requests manually, aren’t you?

yes, I send them manully.

Or check the chart you're using 🙂

I set ClearML up with Kubernetes Helm.

Is this the cloud-ready version? or the legacy chart?

In any case the user associated with the credentials you use is not assigned to the same company ID you replaced

Also - did you start with a fresh DB after changing the default company value?

I set it up with the following documentation: https://allegro.ai/clearml/docs/docs/deploying_clearml/clearml_server_kubernetes_helm.html

Well, for some reason the webserver auth user entry is probably created using the incorrect company_id - the best thing to do it exec into the mongo container and check the actual company value assigned to the webserver user