Use S3 as Your Personal Drive

Reading and writing files on S3

Once you have connected an S3-compatible bucket through GoMount, it appears as a folder in Finder. You can drag files in, double-click documents to open them, and save new files directly into the mounted volume. For day-to-day browsing, the experience feels almost identical to working with a USB drive or a network share.

Behind the scenes, however, every read and write is translated into S3 API calls. When you open a file, GoMount streams the object from the provider on demand. Small files (a few megabytes or less) appear almost instantly because the download completes before your application finishes launching. Larger files show a brief delay while the data transfers, and GoMount's transfer queue tracks progress so you always know what is happening.

Writing works in the opposite direction. When you save a file, GoMount passes the data through rclone to the S3 API. For files under the multipart threshold (typically 5–10 MB, configurable per connection), the upload is a single PutObject call that completes in a fraction of a second on a decent connection. For larger files, rclone automatically switches to multipart upload, splitting the file into chunks that are sent in parallel. You do not need to configure this manually — it happens transparently.

One thing that surprises new users: saving a file does not always feel instantaneous. Unlike a local SSD where a save completes in milliseconds, an S3 save must travel over the network, be acknowledged by the remote server, and then confirmed back. On a fast connection with a nearby provider (for example, Wasabi's US-East endpoint from a New York office), a 1 MB file saves in under a second. From a slower connection or a more distant region, the same save might take two or three seconds. This is normal and expected.

How S3 differs from a local drive

It is tempting to treat a mounted S3 bucket exactly like a local disk, but there are important differences that affect how you should use it. Understanding these differences early will save you from confusing errors and data-loss scares.

• Eventual consistency for some operations. Most S3 providers now offer strong read-after-write consistency for new objects, but overwrite and delete operations may still be eventually consistent on some providers. In practice, this means that if you overwrite a file and immediately re-open it from another device, you might briefly see the old version. For single-user workflows this is rarely an issue; for multi-device sync it is worth knowing about.
• No true file locking. S3 has no concept of an exclusive file lock. If two users (or two apps on the same Mac) write to the same object simultaneously, the last write wins and the other write is silently lost. This is fundamentally different from a local filesystem or a traditional NAS with SMB/NFS locking. Avoid using S3-mounted volumes for databases, spreadsheets with multiple editors, or any application that relies on fsync for data integrity.
• Higher latency per operation. Each file operation involves a network round-trip. Listing a directory with 1,000 files requires fetching the full object listing from the API. Opening a file requires a GET request. This makes S3 unsuitable as a scratch disk for applications that perform thousands of small reads and writes, such as compilers, photo editors with large catalogs, or virtual machine images.
• No in-place modification. S3 objects are immutable once written. When you "edit" a file on a mounted S3 volume, the application writes a completely new object to replace the old one. There is no way to change just a few bytes in the middle of a file. For large files that receive small edits, this means the entire file is re-uploaded each time.
• Folder structure is an illusion. S3 does not have real directories. What looks like a folder hierarchy is actually a flat list of objects with key prefixes separated by slashes. GoMount and rclone create the appearance of directories, but operations like "rename folder" actually require copying every object with the old prefix and then deleting the originals. Renaming a folder with thousands of files can take a long time and incur extra API costs.

Backup workflows with GoMount

One of the best use cases for S3 on macOS is as the off-site leg of a 3-2-1 backup strategy: keep at least three copies of your data, on two different media, with one copy stored off-site. S3-compatible storage is ideal for that off-site copy because it is cheap, durable, and accessible from anywhere.

Here is a practical workflow using GoMount:

1. Stage your backup locally. Let your backup software (Time Machine to a local NAS, Carbon Copy Cloner, or a simple rsync script) write to a local drive first. This keeps the backup fast and lets you verify that the data is correct before it leaves your network.
2. Use GoMount's transfer queue to upload. Once the local backup is complete, use GoMount's built-in transfer queue to copy the backup archive to your S3 bucket. The transfer queue handles large uploads reliably, with automatic retry if the connection drops. You can schedule this as a post-backup step or run it manually.
3. Enable S3 versioning as a safety net. Most S3 providers support object versioning. When versioning is enabled, overwriting or deleting a file does not destroy the previous version — it is kept in the bucket's version history. If you accidentally upload a corrupted backup, you can restore the previous version. Versioning is free on most providers (the old versions count toward storage, but there is no separate charge).
4. Set lifecycle policies to manage costs. Old backup versions accumulate over time. Configure a lifecycle policy to transition versions older than 30 days to a cheaper storage class (such as Wasabi's archive tier or Backblaze B2's B2 Cloud Storage with Backblaze's own lifecycle rules). After 90 days, you can move them to cold storage or delete them entirely, depending on your retention requirements.

Sync strategies: one-way vs. two-way

Syncing files between your Mac and S3 is a common requirement, but the word "sync" means different things to different people. Choosing the right strategy prevents data loss and frustration.

One-way sync (mirror / backup)

In a one-way sync, changes flow in a single direction: from your Mac to S3 (or from S3 to your Mac). This is the safest approach for backups because there is no ambiguity about which side is the source of truth. GoMount's transfer queue supports one-way transfers natively. You can also use rclone sync from the command line for more control over filters, exclusions, and dry-run testing.

One-way sync is ideal when:

• You want a backup copy of a local folder in S3.
• You publish files to S3 for distribution (for example, uploading finished render outputs to a shared bucket).
• You want to mirror a local directory to a second location for disaster recovery.

Two-way sync (bidirectional)

In a two-way sync, changes on either side are propagated to the other. This sounds convenient but introduces complexity: what happens when the same file is modified on both sides? With S3's lack of file locking, conflict resolution becomes your responsibility. Tools like rclone bisync handle this by tracking change lists and flagging conflicts rather than silently overwriting.

Two-way sync makes sense only for specific working folders where you genuinely need the same files available on your Mac and in S3, and where you are the sole editor. For shared folders with multiple contributors, use a purpose-built collaboration tool instead.

Working with large files

S3 and GoMount handle large files well, but there are a few things to keep in mind to avoid surprises.

Multipart upload kicks in automatically when a file exceeds the configured threshold (default is usually 5 MB). GoMount splits the file into parts (typically 5–16 MB each) and uploads them in parallel. For a 2 GB video file on a 100 Mbps connection, multipart upload completes in roughly three minutes. Without multipart, a single interrupted upload would have to restart from the beginning; with multipart, only the failed parts need to be retried.

Files larger than 5 GB require multipart upload by S3 specification. GoMount handles this transparently, but be aware that some S3-compatible providers have lower limits on the number of parts per upload. If you encounter errors with very large files (above 100 GB), check your provider's documentation for maximum part counts and adjust the part size in GoMount's connection settings.

Bandwidth limits are important if you share your network with other devices. GoMount allows you to set upload and download bandwidth caps in the connection settings. For example, if you have a 500 Mbps connection, you might cap S3 transfers at 100 Mbps to leave headroom for video calls and streaming. Without a cap, a large upload can saturate your upload bandwidth and cause noticeable lag in other applications.

Download behavior deserves special mention. When you double-click a large file on a mounted S3 volume, your Mac's default application starts opening it immediately. For a 10 GB video file, this means the video player starts reading from the beginning while the rest of the file is still downloading. Most modern players handle this gracefully with progressive loading. However, if you need the entire file before working with it (for example, a disk image or a compressed archive), use GoMount's transfer queue to download the file fully first, then open the local copy.

File naming and encoding gotchas

S3 object keys are UTF-8 strings, which means they support a wide range of characters. In practice, however, not all S3-compatible providers handle every character equally well. Here are the rules that will keep you out of trouble:

• Stick to ASCII when possible. File names with accented characters, CJK characters, or emoji generally work, but some providers or tools may mangle them during listing or download. If you share files with collaborators who use different operating systems or tools, ASCII-safe names are the safest choice.
• Avoid colons in file names. macOS displays colons as slashes in Finder and vice versa. A file named report:final.pdf on your Mac may appear as report/final.pdf in the S3 key, creating an unexpected folder level. Use hyphens or underscores instead.
• Avoid leading or trailing spaces. Some S3 providers trim whitespace from object keys, which can cause files to appear with different names than you expect. GoMount preserves spaces, but the provider might not.
• Be careful with special URL characters. Characters like +, %, #, and ? have special meaning in URLs. While S3 supports them in object keys, some tools and web consoles may misinterpret them. If a file seems to be missing when you browse the bucket through a web console, try renaming it to remove special characters.
• Maximum key length. S3 supports object keys up to 1,024 bytes. This is rarely a problem in practice, but deeply nested folder structures with long file names can approach the limit. If you see errors about key length, flatten your folder hierarchy.

GoMount handles most encoding edge cases automatically, converting between macOS's UTF-8 normalization form (NFD) and the form expected by the S3 API. But if you create files through the command line or through scripts, test with a few sample names first to confirm that your provider handles them correctly.

Permission errors and how to fix them

The most common error new GoMount users encounter is a permission denied message when trying to upload, download, or list files. This is almost always caused by an incorrectly configured IAM policy or bucket policy. Here is how to diagnose and fix it.

First, confirm that your access key has the minimum required permissions. For full read-write access through GoMount, your IAM policy needs at least these actions:

• s3:ListBucket — allows listing the contents of a bucket (what you see in Finder when you open the volume).
• s3:GetObject — allows downloading (reading) individual files.
• s3:PutObject — allows uploading (writing) files.
• s3:DeleteObject — allows deleting files. Without this permission, you can upload but not remove files, and operations like "move" (which is copy + delete) will fail.

If you are using AWS IAM, a minimal policy looks like this:

{ "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject"], "Resource": ["arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*"] }

For other providers, the policy format is similar but the resource ARN syntax may differ. Check your provider's documentation for the exact format.

Other common permission issues include:

• Bucket policy conflicts. Even if your IAM policy grants access, a bucket policy that explicitly denies certain actions will override it. Check both the IAM policy and the bucket policy.
• MFA delete. If MFA delete is enabled on the bucket, you cannot delete objects or change the versioning state without providing an MFA code. GoMount does not support MFA delete; disable it on the bucket if you need to manage files through GoMount.
• Object ownership. In AWS S3, the default object ownership setting means that the account that uploads an object owns it. If you upload files with one access key and try to manage them with a different key in the same account, you may encounter access issues. Set the bucket's object ownership to "Bucket owner enforced" to avoid this.
• IP-based restrictions. Some organizations restrict S3 access to specific IP ranges. If you connect from different networks (home, office, coffee shops), make sure your IAM policy does not include an IP condition that blocks your current location.

Cost monitoring and billing alerts

S3-compatible storage is cheap, but "cheap" can still add up if you are not paying attention. The three cost components to watch are storage, requests, and egress.

Storage costs are the most predictable. You pay per gigabyte per month. At Wasabi's $6.99 per TB per month, storing 1 TB costs about $7 per month. At Backblaze B2's $0.005 per GB per month, the same 1 TB costs about $5 per month. These are low, but if your bucket grows to 10 TB or 50 TB over time, the bill grows proportionally.

Request costs are usually small but can surprise you when you have many small files. AWS S3 charges $0.0004 per 1,000 PUT requests and $0.0004 per 1,000 GET requests. If you have a bucket with 10 million small files and your backup workflow re-uploads all of them daily, you are making 10 million PUT requests per day, which costs about $4 per day or $120 per month. Most providers have similar request pricing. Wasabi and Cloudflare R2 do not charge for requests at all, which makes them attractive for high-file-count workloads.

Egress costs depend on your provider and your download patterns. As discussed in our S3 vs cloud drives comparison, egress fees can erase storage savings if you choose the wrong provider. If you download large amounts of data regularly, choose a provider with low or zero egress fees.

To keep costs under control:

• Set up billing alerts. On AWS, create a budget in AWS Budgets that sends you an email when your monthly bill exceeds a threshold you define. On Wasabi, Backblaze, or Cloudflare, set up similar alerts in the billing dashboard. A $20 surprise bill is easy to ignore; a $200 surprise bill is not.
• Use lifecycle policies. Move files that have not been accessed in 30 days to a cheaper storage class. Move files older than 90 days to archive or cold storage. Delete files you no longer need. Most providers support lifecycle rules that automate this process.
• Avoid unnecessary requests. Do not re-upload files that have not changed. Use checksums or modification timestamps to skip unchanged files in your backup workflow. If you use rclone sync, it already does this by default.
• Monitor bucket size. Check your bucket's total size regularly. On AWS, use the S3 Storage Lens dashboard. On other providers, check the bucket metrics in the web console. If the size is growing faster than expected, you may have a process that is uploading duplicate data.

Best practices summary

The following table summarizes the key takeaways from this guide. Keep it handy as a quick reference for daily S3 usage with GoMount.

Next in this series

This article is part of our S3 cloud storage series for macOS users. If you found this guide helpful, the following articles dive deeper into specific topics:

• Why S3-Compatible Object Storage Beats Paid Cloud Drives — a 3-year cost comparison that shows when S3 saves money and when consumer cloud drives are still the better choice.
• GoMount + Wasabi Setup Guide — step-by-step instructions for connecting Wasabi's low-cost object storage to your Mac through GoMount.
• GoMount + Backblaze B2 / Cloudflare R2 Setup Guide — how to configure Backblaze B2 or Cloudflare R2 as your S3 provider, including the free-egress Cloudflare pairing.
• GoMount + Alibaba Cloud OSS / Tencent COS Setup Guide — for users in the Asia-Pacific region who need domestic S3-compatible storage.
• Getting Started with GoMount — the fundamentals of installing GoMount, connecting your first storage provider, and mounting your first volume.

If you have questions or run into issues, check the guides index or reach out through our contact page.