Skip to content
IP Inlay for FileMaker
← Back to blog

From FileMaker to Finder: Mounting S3 Buckets as a Native Drive

· Gordon Shumway

Give users a normal drive backed by the same bucket your scripts already manage, with two function calls in a startup script.

The problem: FileMaker document management splits in two

Every FileMaker solution that handles real files eventually splits into two worlds. The structured side is fine: records, statuses, approvals, an S3 key stored on each document record. Functions like Inlay_S3_PUT_CONTAINER and Inlay_S3_GET move objects up and down on demand, and the bucket on AWS S3 or DigitalOcean Spaces holds the bytes so your .fmp12 stays lean.

The messy side is the humans. Some users need to browse a whole folder of project files. Some need to drag a PDF into another application or attach a file to an email. Some should only ever look, never touch. Scripting every one of those interactions is where solutions accumulate glue: export-to-temp scripts, a sync app installed per workstation, or a screen share walking a client through Cyberduck and an access key. Three weeks later someone uploads to the wrong prefix and the records point at nothing.

Inlay_S3_MOUNT takes a different path. A FileMaker script mounts a saved S3 profile as a native drive. The user sees a normal drive in the Finder sidebar or in File Explorer, labeled with the config name you chose, and FileMaker stays where the workflow starts.

Why FileMaker cloud storage needs a drive, not a download portal

Keeping scans, photos, video, and generated PDFs in a bucket instead of container fields keeps the FileMaker file small, which means faster backups and cheaper hosting, and it lets other systems read the same storage your solution writes to. But object storage has no desktop presence. Users do not want a download portal; they want a folder. The usual answers, a third-party mount tool licensed per machine or a pile of bespoke helper scripts, put the file access layer outside the solution's control.

Mounting from inside FileMaker closes that gap. The same bucket your scripts manage is also a drive the OS can open, provisioned by the database people already launch every morning. Onboarding is a startup script. Unmounting the drive is one function call.

Use case: a FileMaker document library on DigitalOcean Spaces

A company tracks client projects in FileMaker. Each document record holds the S3 key for a file stored in DigitalOcean Spaces, uploaded by script with Inlay_S3_PUT_CONTAINER so every upload is logged against the record.

The team does not work record by record. They want to open a folder of this week's files. So the startup script saves a config named "ProjectFiles" and mounts it. The user clicks the drive in the Finder sidebar and opens documents in whatever application they normally use. On Windows workstations the files appear as placeholders, and a file downloads only when someone actually opens it. FileMaker remains the system of record for status and approvals. The drive is the human-friendly view of the same bucket.

Startup script: save the config, mount the drive

The flow is always two calls: save the profile, then mount it. Configs live only for the current FileMaker session, so this pair belongs in a startup script, for example one triggered by OnFirstWindowOpen.

# OnFirstWindowOpen: configure and mount the S3 drive.
# Configs are per-session, so this must run every time the file opens.

Set Variable [ $accessKey ; Value: Settings::S3AccessKey ]    # protected field, not a literal
Set Variable [ $secretKey ; Value: Settings::S3SecretKey ]

Set Variable [ $result ; Value:
    Inlay_S3_SET_CONFIG ( JSONSetElement ( "{}" ;
        [ "ConfigKey" ; "prod" ; JSONString ] ;
        [ "Domain" ; "<region>.digitaloceanspaces.com" ; JSONString ] ;
        [ "Region" ; "region" ; JSONString ] ;
        [ "AccessKey" ; $accessKey ; JSONString ] ;
        [ "SecretKey" ; $secretKey ; JSONString ] ;
        [ "Bucket" ; "your-bucket-name" ; JSONString ]
    ) )
]

A few notes on this script:

  • The credentials come from a protected field. Never paste real access keys into a calculation, a script, or anything version-controlled or published. A protected field, a custom function result, or a secure variable set at startup are all fine; literals are not. Every key above is a placeholder.
  • The Domain is any S3-compatible endpoint host, so the same pattern covers AWS S3, DigitalOcean Spaces, and other compatible providers.
  • Check each result so a wrong region or revoked key fails loudly at launch instead of surfacing later as a mysteriously missing drive. Surfacing the raw $result in the failure dialog is what support will ask for anyway.
  • Re-running the script is safe. Registering again under the same config name replaces the existing mount.

Read-only mounts for review and archives

A mounted drive invites editing, and sometimes that is exactly what you do not want. Set ReadOnly to true and the OS cannot write back to the bucket: users can browse, open, and copy files out, but a stray rename or an app autosaving over a source file never reaches the bucket.

Set Variable [ $result ; Value:
    Inlay_S3_MOUNT ( JSONSetElement ( "{}" ;
        [ "Config" ; "archive-2025" ; JSONString ] ;
        [ "Action" ; "register" ; JSONString ] ;
        [ "ReadOnly" ; True ; JSONBoolean ]
    ) )
]

This is the right default for completed-project archives, shared reference libraries, delivered files, or any bucket where FileMaker should be the only writer. A useful pattern: branch on the user's privilege set in the startup script and mount read-only for reviewer roles, writable for the roles that genuinely manage files. For belt and suspenders, pair the read-only mount with credentials that are themselves read-only at the provider, so the restriction is enforced on both ends.

Unmounting the drive

Unmounting is the same function with a different action:

Set Variable [ $result ; Value:
    Inlay_S3_MOUNT ( JSONSetElement ( "{}" ;
        [ "Config" ; "prod" ; JSONString ] ;
        [ "Action" ; "unregister" ; JSONString ]
    ) )
]

A logout or shutdown script is the natural home, and not just for tidiness: once the solution closes, there is no reason the bucket should stay browsable on that machine. You can also mount on demand. A "Browse archive" button that registers a read-only drive, plus a companion step that unregisters it, keeps cold storage reachable in two clicks without sitting in everyone's sidebar all year.

What users see: Finder and File Explorer integration

macOS: a drive in the Finder sidebar

The drive appears in the Finder sidebar under the label you chose as the config name. Users browse folders, open files in native apps, and drag files into emails or other documents like any other location. Nothing about it asks them to learn S3.

Windows: on-demand placeholders in File Explorer

Files appear in File Explorer as on-demand placeholders. Browsing a folder does not download its files; nothing downloads until a file is actually opened, at which point it hydrates transparently. Mounting a large bucket does not mean downloading a large bucket. This is streaming access for browsing, not a full offline copy.

Inlay_S3_MOUNT vs the scripted S3 functions

The mount is for human browsing. The targeted Inlay S3 storage functions are for scripted, record-by-record work. They are complements, not rivals.

Reach for Inlay_S3_MOUNT when users need a normal desktop browsing experience, when files are too large or numerous for container fields, or when a read-only review mount fits the role.

Reach for the companions when the work is precise and scripted:

A healthy solution often uses both: scripted writes for auditability, the mount for browsing.

Full function reference: Inlay_S3_MOUNT documentation

Have questions about this or an idea for Inlay?

Get in touch →