What causes "Not authorized to access this video" in invoke-ai/InvokeAI?

Use an admin token if cross-tenant access is legitimately needed

invoke-ai/InvokeAI · error · HTTPException

Not authorized to access this video

Error message

Not authorized to access this video

What it means

If the video record exists but no ownership/board-visibility rule grants the current user access, _assert_video_read_access raises HTTP 403 "Not authorized to access this video". This is returned instead of 404 precisely when the video exists but the caller (non-admin, not owner, video on a board that is not Shared/Public) may not view it.

Source

Thrown at invokeai/app/api/routers/videos.py:178

    board_id = ApiDependencies.invoker.services.board_video_records.get_board_for_video(video_name)
    if board_id is not None:
        # See `assert_image_read_access`: only a board positively known to be gone may fall
        # through to a refusal; a lookup that cannot be decided propagates instead of
        # impersonating a permission decision.
        try:
            board = ApiDependencies.invoker.services.board_records.get(board_id)
        except BoardRecordNotFoundException:
            pass
        else:
            if board.board_visibility in (BoardVisibility.Shared, BoardVisibility.Public):
                return

    # Gone and denied mean opposite things to a client holding a reference to this video, and
    # nothing above can tell them apart. See `_assert_image_record_exists`.
    if not ApiDependencies.invoker.services.video_records.exists(video_name):
        raise HTTPException(status_code=404, detail="Video not found")
    raise HTTPException(status_code=403, detail="Not authorized to access this video")


def _is_accepted_video_upload(file: UploadFile) -> bool:
    if file.content_type and file.content_type.startswith(ACCEPTED_VIDEO_MIME_PREFIXES):
        return True
    if file.filename:
        return file.filename.lower().endswith(ACCEPTED_VIDEO_EXTENSIONS)
    return False


def _is_mp4_file(path: Path) -> bool:
    try:
        with open(path, "rb") as video_file:
            search_limit = min(path.stat().st_size, 64 * 1024)
            position = 0
            while position + 8 <= search_limit:
                video_file.seek(position)
                header = video_file.read(8)

View on GitHub (pinned to 0b6a024f2f)

Solutions

Use an admin token if cross-tenant access is legitimately needed
Have the video owner move the video to a Public/Shared board
Log in as the owning user
Verify which user the current token resolves to — stale or misconfigured auth often causes unexpected denials

Defensive patterns

Strategy: try-catch

Validate before calling

try:
    requests.get(f"{base}/api/v1/videos/{name}").raise_for_status()
except requests.HTTPError as e:
    assert e.response.status_code != 403, "no read access to this video"

Try / catch

try:
    resp = requests.get(f"{base}/api/v1/videos/{video_name}/full")
    resp.raise_for_status()
except requests.HTTPError as e:
    if e.response.status_code == 403:
        request_access_from_owner(video_name)

Prevention

Never assume possession of a video name implies read access in multiuser mode
Share videos via Public/Shared boards instead of copying names
Audit which user your token resolves to before batch fetches

When it happens

Trigger: GET /api/v1/videos/{video_name}/... in multiuser mode for another tenant's video that sits on a private (or shared-but-not-public per policy) board, using a non-admin token.

Common situations: Multiuser InvokeAI where users exchange video names out-of-band; service tokens for one account fetching another's assets; videos on deleted boards (board lookup fails, falls through to denial).

Related errors

AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/8f812260a717f10c. Report an issue: GitHub.