Budibase/budibase · error · HTTPError

SharePoint drive does not belong to this site

Error message

SharePoint drive does not belong to this site

What it means

fetchSharePointEntriesForOperation resolves a site's drives via listSharePointDrives and then, when a driveId is supplied, verifies that the requested drive actually exists among that site's drives. If no drive in the site's drive list matches the given driveId, it throws this 400 HTTPError. It is a guard against browsing/syncing a drive that belongs to a different (or deleted) site.

Source

Thrown at packages/server/src/sdk/workspace/ai/rag/sources/sharepoint/sharepoint.ts:452

          })
        ),
        ...lists.map(
          (list): KnowledgeSourceEntry => ({
            id: `list:${list.id}`,
            name: list.name,
            path: list.name,
            type: "list",
            listId: list.id,
            webUrl: list.webUrl,
          })
        ),
      ].sort((a, b) => a.name.localeCompare(b.name)),
    }
  }

  const drive = drives.find(candidate => candidate.id === driveId)
  if (!drive) {
    throw new HTTPError("SharePoint drive does not belong to this site", 400)
  }

  const resolvedParentPath = parentPath.trim() || drive.name
  const items = await listSharePointDriveItems(
    bearerToken,
    driveId,
    parentItemId
  )
  return {
    entries: items
      .filter(
        (item): item is SharePointDriveItem & { id: string; name: string } =>
          !!item.id && !!item.name && !!(item.folder || item.file)
      )
      .map(
        (item): KnowledgeSourceEntry => ({
          id: `${driveId}:${item.id}`,
          name: item.name,

View on GitHub (pinned to a81a902e9a)

Solutions

1. Verify the driveId belongs to the same site as source.config.site.id (list the site's drives via the Graph API and match on id)
2. Re-fetch the drive list for the current site and pick the drive fresh instead of using a cached driveId
3. If the site was changed on the source, reconnect/re-save the knowledge source so siteId and driveId are consistent
4. Check the drive still exists in SharePoint (it may have been deleted or recreated with a new id)

Example fix

// before
await fetchSharePointEntriesForOperation({ agentId, operationId, siteId: siteA, driveId: driveFromSiteB })
// after
const drives = await listSharePointDrives(token, siteA)
const drive = drives.find(d => d.name === "Documents")
await fetchSharePointEntriesForOperation({ agentId, operationId, siteId: siteA, driveId: drive.id })

const drives = await listSharePointDrives(bearerToken, siteId)
if (!drives.some(d => d.id === driveId)) {
  throw new Error(`Drive ${driveId} does not belong to site ${siteId}`)
}

const isValidDrive = (driveId: string, drives: { id: string }[]): boolean =>
  drives.some(d => d.id === driveId)

try {
  await fetchSharePointEntriesForOperation({ agentId, operationId, siteId, driveId })
} catch (err) {
  if (err instanceof HTTPError && err.status === 400 && err.message.includes("does not belong to this site")) {
    // refresh drive list and re-pick the drive
  } else { throw err }
}

When it happens

Trigger: Calling the knowledge-source entries browsing flow with a driveId that is not in the drive list returned by the Graph API for the connected site's siteId — e.g. a driveId copied from another site, a stale/renamed drive, or a mismatched siteId+driveId pair.

Common situations: Reusing cached browse results after the source's site was changed; UI sending a driveId from a previously selected site; SharePoint drive deleted or recreated (new drive id); client bug pairing the wrong siteId with a driveId.

Related errors

• Error getting status
• datasourceId and authConfigId are required
• siteId is required
• driveId is required with parentItemId
• Specified SharePoint site is not connected for this operatio

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/1509df953e1d6d7a. Report an issue: GitHub.