This message was deleted.

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.