ios and android apps can log in , but not sync anymore

[matthiasg]

For a few months now, also tried with latest release yesterday, the native iOS and Android apps can login, but not sync anymore. The sync and login api calls are being performed (can be seen in the docker logs), and return 200, but the bitwarden clients still report sync failed.

Anybody else seen this ? Other topics here where about not being able to login, but this is about not being able to sync after the login

[maxnet72]

Exactly the same is happening to me. Two iphones and samsung s22 not syncing with vaultwarden docker version.
The application on windows 11 works without any problems, the same as on the Macbook Pro M1.
The problem is only with the mobile version.
I checked that the mobile version is sending data to vault but not reading.
After deleting all data from the vault, the sync works, no error message.
After restoring the backup, a message appears: synchronization failed.

[BlackDex]

Are there any errors in the Vaultwarden logs?

How many items do these vaults contain?
Which kind of KDF hashing is used?

Which version of Vaultwarden are you using?

[maxnet72]

I don't see any errors in the log.
20.06.2023 22:53:53 [2023-06-20 20:53:53.388][request][INFO] GET /api/sync 20.06.2023 22:53:53 [2023-06-20 20:53:53.399][request][INFO] GET /api/sync 20.06.2023 22:53:53 [2023-06-20 20:53:53.487][response][INFO] (sync) GET /api/sync?<data..> => 200 OK 20.06.2023 22:53:53 [2023-06-20 20:53:53.496][response][INFO] (sync) GET /api/sync?<data..> => 200 OK 20.06.2023 22:53:53 [2023-06-20 20:53:53.965][request][INFO] GET /api/config/ 20.06.2023 22:53:53 [2023-06-20 20:53:53.965][response][INFO] (config) GET /api/config => 200 OK 20.06.2023 22:53:54 [2023-06-20 20:53:54.169][request][INFO] GET /api/config/ 20.06.2023 22:53:54 [2023-06-20 20:53:54.169][response][INFO] (config) GET /api/config => 200 OK 20.06.2023 22:57:27 [2023-06-20 20:57:27.623][request][INFO] GET /api/config 20.06.2023 22:57:27 [2023-06-20 20:57:27.623][response][INFO] (config) GET /api/config => 200 OK

How many items do these vaults contain?
-998 items.

Which kind of KDF hashing is used?
-PBKDF2 SHA-256

Which version of Vaultwarden are you using?

• latest 1.28.1

[BlackDex]

Well so looks ok to me.
Maybe any errors in the reverse proxy logs?
Because it all seems to work. Also because you mention it does work on non mobile devices.

In afraid that we are probably not the right place to debug mobile client issues though.

I would suggest to see if you can reproduce the same issue on vault.bitwarden.com.

The only case i know of with something similar was because there was a very large (secure) note, which caused the mobile client break/crash during decrypting that note.

[maxnet72]

Exactly, vaultwarden via browser and desktop app works fine.

[BlackDex]

Maybe see if using adb logcat gives some info. But we cant really help with that

[matthiasg]

@BlackDex we have this issue too and the keys are mostly automatically generated and we do not use secure notes much if at all. I could trace the http traffic and the exact data returned if that helps, but since it has sensitive passwords i am not sure without looking into it how to secure that.

For testing it might make sense to create a new user on the same vaultwarden instance without access to any of the existing password groups and see whether it can sync though. It would delineate the scope of the issue

[BlackDex]

Well, the problem is that i can't reproduce it. I have test accounts with 6000+ items, and large notes, it all works fine.

And, since the web-vault works, and there are no errors during the response generated by Vaultwarden, it either is a bug in the clients.
Or a small chance it is in the format returned by Vaultwarden. But if that was the case, then i would have suspected a lot more issues.

Maybe you can try to use the :testing tagged images and see if it solves the issues? Which would be strange, since nothing changed in the format as far as i know.

[Jinra]

So this issue was driving me mad (same issue, syncing fine on desktop/extensions, but failing on android), so I spent a couple hours "doing it the hard way" and deleting various entries to see which one will let my vault sync. I found the time the phone last synced (9/26) and deleted recent entries to diagnose. Luckily, I didn't have a to try long until I found that an entry on 9/28 was the culprit.

This entry was a secure note that I can't remember on which client it was created (likely browser plugin or desktop client). Once I removed this secure note, all was well and my android devices can now sync again.

Looking further into it. I think this line specifically is causing the problem.

"secureNote": {
        "type": null
      }

All my other secure notes have a type of 0, but for some reason this note had a type of null. I tried creating another note on the desktop clients of Mac and Windows, as well as the browser extension for Firefox, but I could not replicate the issue. I didn't bother testing android since the problem synced from another origin.

I'm not sure if this is the same root cause as what you're experiencing @matthiasg @maxnet72, but might be worth checking your type value for your secure notes.

[GasperSB]

I also experienced this issue. Make sure you completely remove the note(s) in question. This means removing it from the Trash folder as well (permanently delete).

[XPlantefeve]

And with that you saved me.

Note for those who wonder: the "type": null is to be searched in an json unencrypted export of the web vault.

Since several persons are impacted, maybe this should be raised to an issue?

[tm9k1]

I agree. Someone needs to fix this.
Somehow usually "type": 0 is observed in the json. I wonder if something goes wrong inside the creation of a note that forces a null to pop up there..

[zacknewman]

I agree. Someone needs to fix this.

So create a bug/issue and perhaps a corresponding git format-patch or PR that fixes it. It would appear that this is both a client and server issue. A client issue in that the type of a secure note should only ever be 0, but a server issue in that it should only accept 0. Currently Vaultwarden models secure notes as raw JSON instead of strongly typing it like upstream does.

That's a pretty easy fix since CipherSecureNoteModel only contains the single field for the SecureNoteType.