OneDrive backup fails with 401 on file upload, seconds after authenticated directory creation succeeds

Bug Reports
,
1

REPRODUCIBILITY: 100%
OS VERSION: 5.2.0.17
HARDWARE: Jolla Phone (2026)
UI LANGUAGE: Polish
REGRESSION: no

DESCRIPTION:
Backup to OneDrive fails at the upload stage. The backup archive is
created correctly and the remote directory is created successfully, but
the subsequent file upload is rejected with HTTP 401 “unauthenticated” —
about three seconds after requests on the same account and token were
accepted by the server.

PRECONDITIONS:
A personal Microsoft account configured in Settings > Accounts.

STEPS TO REPRODUCE:

  1. Add a personal Microsoft (OneDrive) account in Settings > Accounts
  2. Settings > Backup, select OneDrive as destination
  3. Trigger a manual backup

EXPECTED RESULT:
Backup archive is uploaded to OneDrive.

ACTUAL RESULT:
Backup fails with an upload error. Log shows HTTP 401 on the upload
request.

MODIFICATIONS: none

ADDITIONAL INFORMATION:

Possibly the same issue as reported here for 5.1.0.x on Xperia 10 III:

I am opening a separate report because the device and OS version differ,
and because I have log detail that thread does not contain. Feel free to
merge if they turn out to share a root cause.

Log excerpt:

[sailfish-backup] “Requesting sync profile onedrive.Backup-12 to upload
file …/sailfish_backup_2026-09-13T10-01-19Z.tar.gz”
[sailfish-backup] “Status: UploadingBackup”
buteo-oopp-runner: “Backup” request with account 12 experienced error:
ContentConflictError HTTP code: 409 data: {“error”:{“code”:
“nameAlreadyExists”,“message”:“Name already exists”, …}}
buteo-oopp-runner: “Backup” request with account 12 experienced error:
ContentConflictError HTTP code: 409 (second occurrence)
buteo-oopp-runner: “Backup” request with account 12 experienced error:
AuthenticationRequiredError HTTP code: 401 data: {“error”:{“code”:
“unauthenticated”,“message”:“Unauthenticated”}}
buteo-oopp-runner: failed to backup file: “…/onedrive.Backup-12”
“sailfish_backup_2026-09-13T10-01-19Z.tar.gz” to:
“Backups/Jolla-Phone-(2026)_reabTxc6o8TF” for OneDrive account: 12,
code: 401 response: “”
[sailfish-backup] “Error! error=CloudUploadError errorString=
onedrive.Backup-12 update failed, details: 501”

Key observation:
The two 409 responses are harmless (the target directories already
exist), but they prove those requests were authenticated — an invalid
token would return 401, not 409. The 401 then appears three seconds
later on the upload request, using the same account and the same token.
This suggests the upload request is constructed differently from the
directory-creation requests: either it does not carry the authorization
header, or it targets an endpoint where the token is not accepted.

Note: “details: 501” in the final line is an internal error code from
the backup layer, not an HTTP status — every actual HTTP status in this
log is explicitly labelled as such.

Ruled out:

  • Account/credentials: removed and re-added the account several times,
    each time producing a new account id (12, 13, …). No change.
  • Permissions: the Microsoft account consent page lists Sailfish OS with
    “open and edit your OneDrive files” plus offline access, so write
    access is granted.
  • Stale remote files / name conflicts: deleted the remote directory and
    the account, then retried against a clean target. Same failure.
  • Network path: reproduced identically on Wi-Fi and on mobile data.
  • Local state: the archive is created successfully and is present on
    disk during the upload window.

Second symptom, possibly the same root cause:
On the same device, adding a Microsoft 365 account in Settings >
Accounts fails with a generic “an error occurred”. This is a personal
consumer account, so no organisational conditional
access policy is involved. The Microsoft Outlook app running under
Android AppSupport signs into the same account without any problem,
which indicates the account, the credentials and the network are fine
and points at the native account integration layer.

Given that both symptoms involve personal Microsoft accounts and both
fail specifically on operations requiring write or full account access,
they may share a cause in the account/authentication layer rather than
being two independent bugs.

1 Like
2

Thanks for doing this.
How is the outcome when using OD in gallery? Can you view and open pictures?
X10 III for me 5.1.0.11

3

Thanks for asking — I checked, and it fails in a way that looks closely related.

Thumbnails and album listing work (partially). Opening a picture does not: it spins and ends with “Could not download”. The log shows the same pattern as the backup case — buteo-oopp-runner successfully syncs the same account against Graph at that very moment, while jolla-gallery gets 401 on the content endpoint seconds later:

[W] AbstractImageDownloader::about to fetch image:
  "https://graph.microsoft.com/v1.0/me/drive/items/<ID>/content"
[W] Downloaded file is not an image, mime type is "text/plain"
[D] Got text instead: {"error":{"code":"unauthenticated","message":"Unauthenticated"}}
[W] SocialImageDownloader: failed to download ".../content"

So again: read/list requests on the account are accepted, the file-fetch request right after is not. Gallery then falls back to a freshly generated pre-authenticated download.aspx?...&tempauth=... URL (expiry an hour ahead, so valid credentials are clearly obtainable at that point) — that one also fails to deliver the file, silently, with no error line.

One extra quirk, probably separate: images.thumbnailUrl in onedrive.db stores URLs with an embedded tempauth token and never refreshes them, because re-sync logs album ... doesn't need update and skips the row. Once the token expires, every thumbnail returns 401 and the album renders empty. Deleting ~/.local/share/system/privileged/Images/onedrive.db and forcing a full sync brings thumbnails back — full-size pictures still fail.