Hi team, I need help with a Rancher 2.14.x login issue on our management cluster. Environment: - Rancher: upgraded from v2.14.2 to v2.14.3 - Helm chart: rancher-2.14.3 - Kubernetes: k3s v1.34.8+k3s1 - Helm client: v3.21.2 Problem: The Rancher UI login still fails after entering valid admin credentials. Browser/network shows the failing API as: POST /v1/ext.cattle.io.selfuser HTTP 404 What I verified: 1. Rancher backend login works: - POST /v3-public/localProviders/local?action=login returns HTTP 201 - Token is successfully generated 2. The selfuser endpoint fails: - POST /v1/ext.cattle.io.selfuser returns HTTP 404 - This happens even when port-forwarding directly to the Rancher pod, so it does not look like browser, ingress, service, or port-forward routing issue. 3. Kubernetes API aggregation for ext.cattle.io appears healthy: - APIService v1.ext.cattle.io is Available=True - kubectl get --raw /apis/ext.cattle.io/v1 lists selfusers - kubectl create SelfUser returns system:admin 4. metrics-server issue was also fixed: - v1beta1.metrics.k8s.io is now Available=True - kubectl top nodes works History: - Rancher v2.9.2 was installed earlier and login worked. - We removed that and installed Rancher v2.14.2. - v2.14.2 had the UI login issue. - We upgraded to v2.14.3, but the same /v1/ext.cattle.io.selfuser 404 remains. Current evidence: - Login API: HTTP 201 - Token generated successfully - /v1/ext.cattle.io.selfuser: HTTP 404 - /v1/schemas does not show ext.cattle.io resources - Direct Kubernetes ext.cattle.io SelfUser test works Question: Is this a known Rancher v2.14.3 issue with Kubernetes/k3s v1.34, or could this be stale state from the previous uninstall/reinstall/upgrade path? Is there a supported fix to make Rancher /v1 register ext.cattle.io.selfuser, or should we rebuild the Rancher management cluster cleanly?

You cannot upgrade directly from rancher 2.9 to 2.14. what do you mean by you "removed" rancher 2.9?

/v3-public/localProviders

hasn't been used for log in for a while. though diving in at this level, with schemas as well, is a little too deep to being with.

The Rancher UI login still fails after entering valid admin credentials.

can you provide more detail? what's shown on screen, is there a message? at what stage does it fail (user loads the page, user tries to log in but it doesn't succeed, etc)?

/v1/ext.cattle.io.selfuser

is a relatively new feature that covers a lot of functionality. it's expected for this, at times, to 401 but not 404. this does feel env related, would agree with Brandon can you provide more detail on how you when from 2.9 to 2.14, also is it in the same cluster?

Thanks @creamy-pencil-82913 @stocky-account-63046. Let me clarify the 2.9 -> 2.14 part. I did not do a direct Helm upgrade from Rancher 2.9 to 2.14. I removed the old Rancher installation before installing 2.14.2 What happened was: - Rancher v2.9.2 was previously installed in this same k3s management cluster and UI login was working. - We then removed the old Rancher install and installed Rancher v2.14.2 fresh. - After installing 2.14.2, UI login started failing. - We then upgraded Rancher from v2.14.2 to v2.14.3. - The issue still remains on v2.14.3. UI behavior: - Rancher login page loads successfully. - I enter the local admin username/password. - After submitting, login does not complete and the UI stays/fails at login. - In browser dev tools, I see the request to

/v1/ext.cattle.io.selfuser

returning HTTP 404. - I do not see a normal invalid-password type message because backend login itself succeeds. What I tested: -

/v3-public/localProviders/local?action=login

returns HTTP 201 and generates a token. - Using that token,

POST /v1/ext.cattle.io.selfuser

returns HTTP 404. - This also happens when port-forwarding directly to the Rancher pod, so I do not think this is ingress/service routing/browser cache. -

/v1/schemas

does not show the expected

<http://ext.cattle.io|ext.cattle.io>

resources. - Kubernetes aggregation looks healthy: -

<http://v1.ext.cattle.io|v1.ext.cattle.io>

APIService is Available=True. -

kubectl get --raw /apis/ext.cattle.io/v1

lists selfusers. - Direct kubectl SelfUser test works. 1. Is installing Rancher 2.14.x into the same cluster after removing 2.9.x unsupported unless all Rancher resources/CRDs/state are fully cleaned? 2. Is there a supported cleanup procedure for stale Rancher resources from the old 2.9 install?

it feels like you're on the right path, generally it's better to nuke the cluster and start again. if you just `helm uninstall`ed there's probably lots of things floating around i don't think there's a supported way to completely remove a previous rancher, however you could use this at your own risk. don't think it cleans up anything that was created when using rancher, just resources that rancher itself used / owns

Hi @stocky-account-63046 didn't get a chance to reply back but rancher-cleanup script really helped, thanks for the help.