My odrive2 account seems to have vanished

I’ve been dealing with some really strange odrive2 issues since morning, culminating in not being able to login at all…

At first, my odrive2 sync agent started crashing a few seconds after launch. The message would say something like “a necessary process has unexpectedly stopped”. When nothing helped, I decided to reinstall the agent. After I did, I tried to login to my account ( But the agent keeps telling me the account doesn’t exist…

I’m not sure what to think. Any help would be very welcome.
Thank you,

Hi @alexeybgs,
Are you able to login to the web client a

If so, take a look at the odrive2 tray menu and see if there is an option to deauthorize. If so, select that option. It will make sure the cache is reinitialized and may push past the error you are seeing.

Yes, I can login to the web site. But not to the agent. This is what I get:

There is no “deauthorize” item in the tray menu…
Is there maybe a way to reinitialize the cache manually?

Hi @alexeybgs,
Give this a shot, when you get a chance, to ensure that everything is fresh:
1 - Uninstall odrive2beta
2 - Delete the entire %userprofile%\AppData\Local\odrive2beta folder. This will be a path like C:\Users\[your user name]\AppData\Local\odrive2beta
3 - Restart Windows
4 - Install odrive2beta again

Unfortunately, this didn’t help. I still get exactly the same message…

I’m actually in the same boat. The only difference for me is it’s a new computer and a new installation of odrive2. This machine has never had odrive installed on it before. Can log into the web fine but… the windows client gets the exact same message as above. So this is clearly not a cache issue.

Looks to me like when it calls through the websocket, it’s getting back a 404.

I’d also probably recommend that you guys implement at a minimum SSL pinning, so people can’t easily intercept the traffic.

Hi @naterik @alexeybgs,
Can you uninstall and reinstall.

There was a recent in-place update made to the client installation package that was misconfigured and caused this failure on user id lookup. This has been corrected.

I can confirm that this fixes the issue.

However I would still like to see better security on the client and web socket requests as just taking a quick look shows my full name, email, last 4 of my credit card, credit card expiration, etc.

Hi @naterik,
Thanks for confirming the fix!

For the information you are seeing, are you talking about the information accessible on the odrive2 web client?

There are further, underlying security checks, in addition to SSL certificate use, as part of the odrive2 client<->server handshake and request authorization/validation process. These checks ensure communication is occurring between legitimate and authorized clients and endpoints.

No I’m talking about the information coming from the API requests that the Windows client is making. Using a web proxy and adding it’s certificate as a root CA on Windows, you can decrypt all the traffic between the windows client and the server. If the client was configured to use SSL Pinning, it would identify the MITM and know not to transmit any data while being proxied.

Thanks for the clarification @naterik.

The concern is that a phony certificate could be created by a compromised certificate authority, or, in your testing case, a self-installed root certificate and then used for a MITM attack.

I have passed on your concern to the team. I know that in the past we have deployed clients with our own, built-in certificate store instead of relying on the OS’s, but that is not implemented in the odrive2 beta client. Other ideas like certificate pinning and certificate transparency have been discussed, but not implemented yet.

Thanks @Tony
This fixed the problem on my PC as well.