Hi,
I have one because it happens to me too, in a different way maybe.
Airtable import fails to import attachment files from a public shared view
Description
When importing an Airtable base into Baserow using a public Airtable share URL, none of the files contained in the Airtable attachment field are imported.
The attachment field itself is created in Baserow, but all of its cells remain empty.
Baserow generates one import report entry per attachment, with messages similar to:
File | Cell | Achats | Other
Field: Attachments, Row: 1, File: .directUploadAttachment_965032fa5d295852d6acee71148a3d26_25069f32
The affected Airtable field is a standard multipleAttachments field named Attachments.
Environment
-
Baserow version: 2.3.3
-
Installation type: self-hosted
-
Host: Synology NAS
-
Deployment: Container Manager / Docker
-
Airtable import method: public Airtable share URL
-
Imported table: Achats
-
Attachment field: Attachments
Steps to reproduce
-
Create or use an Airtable base containing a standard attachment field.
-
Add image files to that attachment field by importing them from external URLs.
-
Create a public Airtable share URL.
-
Open the public URL in a private browser window and confirm that:
-
the images are visible;
-
the images can be opened;
-
the images can be downloaded;
-
the downloaded files are valid image files.
-
In Baserow 2.3.3, create a new database by importing the Airtable public share URL.
-
Make sure that file importing is not skipped.
-
Wait for the import to finish.
-
Open the imported table and inspect the attachment field.
-
Open the Baserow Airtable import report.
Expected behavior
Baserow should:
-
download every Airtable attachment;
-
upload it to Baserow’s own file storage;
-
preserve the attachment in the corresponding row;
-
preserve or reconstruct a valid filename and file extension when possible.
Actual behavior
-
The Attachments field is created.
-
None of the attachment cells contain files.
-
The import report contains one error per file.
-
The reported filenames use Airtable internal-looking names such as:
.directUploadAttachment_965032fa5d295852d6acee71148a3d26_25069f32
- No useful error details are provided beyond the generic category
Other.
Checks already performed
Airtable public access
The same public Airtable share URL was opened in a private browser window without being logged into Airtable.
The attachments could be:
This indicates that the attachment URLs are publicly accessible.
Baserow file storage
A new image was manually uploaded into the same Baserow attachment field.
The image remained available after reloading the page.
This indicates that Baserow’s file storage and persistence are working correctly.
Comparison with NocoDB
The same Airtable public share URL was imported into a self-hosted NocoDB instance.
NocoDB successfully downloaded and imported the attachment images.
This suggests that the source files and the Airtable public share permissions are valid, and that the issue is specific to Baserow’s Airtable attachment importer.
Additional information
The files were originally added to Airtable using external image URLs. However, Airtable exposes them as normal attachments, and they can be downloaded from the public shared view.
The Airtable schema identifies the field as:
{
"type": "multipleAttachments",
"name": "Attachments"
}
The issue affects all tested attachments, not just a single file or row.
Possible area to investigate
The import report appears to treat Airtable’s .directUploadAttachment path component as the filename, without a recognizable file extension.
It may be useful to check whether the importer correctly handles:
-
Airtable .directUploadAttachment URLs;
-
filenames missing from the final URL path;
-
filenames provided through HTTP response headers;
-
MIME-type-based extension detection;
-
redirects from Airtable’s attachment CDN;
-
attachment responses without a Content-Length header;
-
URL-encoded or temporary Airtable attachment URLs.
Requested improvement
Please provide more detailed error information in the import report when an attachment download fails, including where possible:
The current generic Other status does not provide enough information to diagnose the failed attachment imports.
