Boards Attachments Invisible After MySQL to PostgreSQL Migration

Applies to: Mattermost Server v11.7.7 and later; Boards (focalboard) 9.2.6 and later; MySQL-to-PostgreSQL migrations using pgloader

Symptoms: After migrating from MySQL to PostgreSQL and upgrading Boards from 9.2.2 to 9.2.6, attachments and images uploaded to Boards before the migration are no longer visible - they display as blank white boxes with no filename or download option.

🛑 Problem

Boards 9.2.6 introduced a stricter file path format for attachments: boards/YYYYMMDD/{boardID}/{filename}. The previous format used by Boards 9.2.2 and earlier did not include the board ID segment: boards/YYYYMMDD/{filename}.

When pgloader migrates the fileinfo table from MySQL to PostgreSQL, it copies the path values verbatim. Records created before the upgrade retain the old path format. When Boards 9.2.6 attempts to serve those files, it validates the path against the expected format and rejects any record whose path does not contain the board ID. The files still exist in object storage and their database records are intact; the server simply refuses to serve them.

Newly uploaded attachments (created after the migration) are stored in the new format and work correctly.

This is a confirmed defect tracked as MM-70411.

Symptoms

Users or administrators experiencing this issue will see:

error: file does not belong to the specified board

This error appears in server logs (searchable via CloudWatch or equivalent). On active deployments it can occur hundreds of times per day.

Additional symptoms:

• Boards attachments and images uploaded before the MySQL-to-PostgreSQL migration display as blank white boxes
• No filename, file size, or download link is shown for affected attachments
• Clicking or hovering on the blank box produces no action
• Attachments uploaded after the migration display and download correctly
• The fileinfo records for affected files are present in PostgreSQL and are not soft-deleted (deleteat = 0)
• The focalboard_blocks records for those files exist and reference the correct board_id
• The mismatch is in the path column of fileinfo: old records use boards/YYYYMMDD/7filename.ext; new records use boards/YYYYMMDD/{boardID}/7filename.ext or 0/{boardID}/7filename.ext

✅ Solution

No patched release is available as of this writing. The diagnostic steps below confirm the root cause. Remediation requires a database update to align old fileinfo paths with the format Boards 9.2.6 expects, and must not be attempted without guidance from Mattermost Support or until an official fix or migration script is published.

Step 1: Confirm the Root Cause

Run the following query on your PostgreSQL database to inspect the path format of Boards-owned file records:

SELECT id, name, path, createat, deleteat
FROM fileinfo
WHERE creatorid = 'boards' AND deleteat = 0
ORDER BY createat ASC
LIMIT 50;

If the path column contains values in the format boards/YYYYMMDD/7filename.ext (no board ID between the date and filename), those records are affected. Compare against focalboard_blocks to confirm the correct board_id for each file:

SELECT id, insert_at, parent_id, board_id, type, fields
FROM focalboard_blocks
WHERE type IN ('attachment', 'image');

Match each block's fields-'fileId' value to the name column in fileinfo to find the correct board_id for each affected path.

Step 2: Check Production Log Volume

Confirm the scope of impact in production by searching logs for the error string:

file does not belong to the specified board

⚠️ Important: Do not manually update fileinfo.path values without a tested, reversible migration script. Incorrect path updates will make files permanently inaccessible from both the database and object storage. Take a database backup before any remediation attempt.

Additional Resources

For more information, see:

Migrate from MySQL to PostgreSQL

Mattermost Boards Documentation