OneDrive Personal Account Root ID for users globally is being changed to include 'sea8cc6beffdb43d7976fbc7da445c639'

[abraunegg]

Category

• Question
• Documentation issue
• Bug

Expected or Desired Behavior

@ificator
The root id should return the correct value and not be a munged string: driveId!sea8cc6beffdb43d7976fbc7da445c639

As there is zero information as to why this is occurring, it would be good to get an explanation as well.

Observed Behavior

@ificator
The API is responding with invalid id details - example for Request URL = https://graph.microsoft.com/v1.0/me/drive/root

{
	"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('XXXXXXXXXXXXXXXXXXX')/drive/root/$entity",
	"createdDateTime": "2025-02-05T16:14:51Z",
	"eTag": "\"{937A68FD-5DBB-40DD-BB19-23EA5EC00160},337\"",
	"id": "7DDA670C5E7F91DF!sea8cc6beffdb43d7976fbc7da445c639",
	"lastModifiedDateTime": "2025-02-19T19:04:58Z",
	"name": "root",
	"webUrl": "https://onedrive.live.com?cid=7DDA670C5E7F91DF&id=01NWGNQTF6Y2GOVW7725BZO354PWSELRRZ",
	"size": 493382267257,
	"createdBy": {
		"user": {
			"email": "XXXXXXXXXXXXXXXXXXXXXXXXX",
			"displayName": "XXXXXXXXXXXXXXXXXXX"
		}
	},
	"parentReference": {
		"driveType": "personal",
		"driveId": "7DDA670C5E7F91DF"
	},
	"fileSystemInfo": {
		"createdDateTime": "2025-02-05T16:14:51Z",
		"lastModifiedDateTime": "2025-02-19T19:04:58Z"
	},
	"folder": {
		"childCount": 30,
		"view": {
			"sortBy": "name",
			"sortOrder": "ascending",
			"viewType": "thumbnails"
		}
	},
	"root": {}
}

Steps to Reproduce

@ificator
Unknown steps to reproduce. I cannot reproduce this in Australia, however random users accessing the service in Europe are hitting this issue.

Known references for 'sea8cc6beffdb43d7976fbc7da445c639' within issues | bug reports | Internet:

• Bug: Incorrect backup target abraunegg/onedrive#2593
• Bug: Skipping uploading modified file due to insufficient free space available on Microsoft OneDrive abraunegg/onedrive#2623
• Bug: Files with newer timestamp are not chosen as version to be kept abraunegg/onedrive#2626
• Bug: HTTPS access timeout after reboot the router abraunegg/onedrive#2798
• Bug: Real-time synchronization is not occurring when using --monitor and sync_list abraunegg/onedrive#2832
• API Bug: Not syncing shared items between personal accounts abraunegg/onedrive#2957
• Bug: Can't see shared folders in personal Office365 accounts abraunegg/onedrive#3103
• Bug: Onedrive crashes due to shared folder not being found at expected location abraunegg/onedrive#3127
• Can't sync Personal shared folders in Office365 family account abraunegg/onedrive#3104
• Unable to sync Personal Shared Folders abraunegg/onedrive#2933
• High CPU Usage and apparent crash abraunegg/onedrive#3125
• https://learn.microsoft.com/en-us/answers/questions/2047001/search-for-files-in-the-drive-and-return-an-empty
• https://forum.rclone.org/t/onedrive-reading-file-error-io-error-unauthenticated-unauthenticated/44846/21?page=2
• https://forum.rclone.org/t/cryptcheck-on-encrypted-onedrive-personal-failed-with-unauthenticated-error/44581
• https://learn.microsoft.com/en-us/answers/questions/1644987/fileopenuserunauthorized-for-workbook-microsoft-gr
• https://4pda.to/forum/index.php?showtopic=275306&st=7020

[ ]: http://aka.ms/onedrive-api-issues
[x]: http://aka.ms/onedrive-api-issues

[abraunegg]

@chackman , @rgregg , @ificator
Please can you look at this issue - it is significant and is impacting users heavily.

[abraunegg]

@nathan-gs
Given your employer - can you please reach out internally to someone on the OneDrive development team and ask them to get in contact to help understand and solve this issue.

[ngoonee]

Hi, generally I think +1 is frowned upon, but I thought I would add that I'm also affected by this issue (my account is based in Malaysia, South-East Asia, not anywhere in Europe). @abraunegg as I have a paid account, should I use/link this issue in my complaint/issue raised to Microsoft?

[dazzag24]

I have a paid MS O365 account and have filed a support issue.

[rgregg]

Thanks for flagging this issue. I've forwarded this on to the engineering team and will report back as soon as I hear something.

[abraunegg]

@rgregg

Thanks for flagging this issue. I've forwarded this on to the engineering team and will report back as soon as I hear something.

Thankyou - can you please get your engineering team to also contact me and/or give me an avenue of contact so that there can be some sort of direct line of communication?

[rgregg-msft]

@abraunegg and others - can you provide more details about what is breaking for you here? The format of the identifiers was not defined and should be treated as an opaque string. The new format of the identifiers is expected as we're making some backend changes to how OneDrive consumer accounts work.

This issue doesn't cover the impact of the ID changing - only that it is different than you had expected. Are you making some assumptions about the format of the ID that is impacting your solution?

[abraunegg]

@rgregg-msft

@abraunegg and others - can you provide more details about what is breaking for you here? The format of the identifiers was not defined and should be treated as an opaque string. The new format of the identifiers is expected as we're making some backend changes to how OneDrive consumer accounts work.

This issue doesn't cover the impact of the ID changing - only that it is different than you had expected. Are you making some assumptions about the format of the ID that is impacting your solution?

It is best we communicate via email or via MS Teams and I can explain what is going on.

Essentially, the Drive ID value for the https://graph.microsoft.com/v1.0/me/drive/root response has changed, but when a Shared Folder from that users root (with the new address format) is added to another users account , the Graph API data for that shared folder root is , for example , responded as !101 or similar ... so the queries then break as the ID is not matching between the two entries.

I would also expect that is Microsoft is changing the API specification and/or changing the identifiers, that this would be clearly documented somewhere with examples and the reason for doing it. The vacuum of silence and zero information is not good.

[patrick-rodgers]

Hey @abraunegg

Essentially, the Drive ID value for the https://graph.microsoft.com/v1.0/me/drive/root response has changed, but when a Shared Folder from that users root (with the new address format) is added to another users account , the Graph API data for that shared folder root is , for example , responded as !101 or similar ... so the queries then break as the ID is not matching between the two entries.

It sounds like the issue you are facing is with sharing? Can you outline the steps to repro the issue. What does "added to another users account" mean in your scenario?

[abraunegg]

@patrick-rodgers
When users add a Shared Folder to their account via the 'Add to my OneDrive' this creates a Shared Folder link online.

When the API data is queried, if that Shared folder is on the 'root' of their account - which it generally is as Personal Accounts do not allow Shared Folder to be be created anywhere other than their root, when you query the API for the Shared Folder details, it returns various elements under the 'remote' and/or 'shared' JSON response.

Those responses then are inconsistent when checking the remote root account details for referential integrity, causing breakage.

Additionally, this data is also in-consistent - as the drive id value itself , which is supposed to be a 16 character value, gets returned as a 15 character value if the remove drive id starts with a zero. Specific evidence is here: abraunegg/onedrive#3072 (comment)

[patrick-rodgers]

Hi @abraunegg,

Here is what I have tried so far:

This appears to only affect ODC -> ODC sharing. I do not have the add to my OneDrive option when sharing ODB ->ODC. Yes?

Setup

1. Create folder, add a couple files in ODC1
2. Share that folder to ODC2
3. Open folder as ODC2 user, click "Add to My OneDrive" link at top, folder appears in ODC2 user's OneDrive root

Testing

• Shared folder is not returned by /me/drive/root/children. Expected as it is not a child of that root. Expected, yes?
• Shared folder is returned by /me/insights/shared. Id is a random string, unrelated to a real drive id. Expected, yes?
• Access the item directly using /me/drive/items/{item id from above}, results in 404. Expected, yes?
• Determine the actual local driveitem id, query /me/drive/items/{local item id} get back details including "remoteItem" facet with an id pointing to remote drive item. Works as expected.
• Now if I take the id from remoteItem from ODC2 and make a query in ODC1 to /me/drive/items/{remoteItemIdFromODC2} I get back the item as expected.

Unsure given the above what is the issue?

Those responses then are inconsistent when checking the remote root account details for referential integrity, causing breakage

Can you elaborate?

[abraunegg]

@patrick-rodgers

Unsure given the above what is the issue?

There are a number of issues and inconsistencies with this item

[parentReference][driveId]
[parentReference][id]

[remoteItem][parentReference][driveId]
[remoteItem][id]

The inconsistencies are:

1. If the [remoteItem][parentReference][driveId] is on a driveId that starts with a zero, the API drops this in the responses. Please read Bug: A database consistency issue has been caught due to 15 character driveId API bug abraunegg/onedrive#3072 (comment) for evidence. This creates a 15 character driveId which then is invalid for any queries and or correct matching.

2. If the the JSON element in the my folder is queried, so I can determine where the shared endpoint is, the driveId values in one response are all lower case, but when the remote folder is checked, these are returned as uppercase which is 100% totally different and this appears to only occur when that Shared Folder resides on an account that their 'root' id now includes the 'sea8xxxx' string

Example for point 2

JSON in User Folder, for the 'Shared Folder'

JSON for Shared Folder in User that Shared Folder with me

The expectation here is consistency. For as long as I have been using & developing the OneDrive Client - OneDrive Personal Account Drive ID's have been:

• 16 Characters Long
• Lower Case

The change that is being made to make the [drive][id] value E99CE85DFD52FEA7!sea8cc6beffdb43d7976fbc7da445c639 is breaking this consistency.

THIS is your issue.

[abraunegg]

@patrick-rodgers
And here is your evidence of your 15 Character problem that relates to the 'sea8cc6beffdb43d7976fbc7da445c639' problem

JSON in User Folder, for the 'Shared Folder'

JSON for Shared Folder in User that Shared Folder with me