S3 Mountpoint lets you treat your Amazon S3 buckets like local directories on a Linux server, enabling standard file system operations on object storage.
Let’s see it in action. Imagine you have an S3 bucket named my-awesome-bucket and you want to access its contents from /mnt/s3.
First, you need to install s3fs-fuse. On Ubuntu/Debian:
sudo apt update
sudo apt install s3fs
On Fedora/CentOS/RHEL:
sudo yum install epel-release
sudo yum install s3fs-fuse
Next, you’ll need AWS credentials. The easiest way is to create a ~/.passwd-s3fs file with your access key and secret key, separated by a colon:
YOUR_ACCESS_KEY_ID:YOUR_SECRET_ACCESS_KEY
Secure this file:
chmod 600 ~/.passwd-s3fs
Now, create the mount point directory:
sudo mkdir /mnt/s3
And mount your bucket:
sudo s3fs my-awesome-bucket /mnt/s3 -o passwd_file=~/.passwd-s3fs,url=https://s3.amazonaws.com
If you’re using a region other than us-east-1, specify it with url:
sudo s3fs my-awesome-bucket /mnt/s3 -o passwd_file=~/.passwd-s3fs,url=https://s3.us-west-2.amazonaws.com
You can now cd /mnt/s3, ls, cp, mv, rm files as if they were local.
cd /mnt/s3
ls
# Output will be your S3 bucket contents
echo "Hello from S3 mount!" > my-test-file.txt
ls
# my-test-file.txt should appear
cat my-test-file.txt
# Hello from S3 mount! should be displayed
To unmount:
sudo umount /mnt/s3
The core problem s3fs-fuse solves is bridging the object storage paradigm of S3 (key-value pairs, eventual consistency, HTTP API) with the block storage paradigm of a POSIX filesystem (files, directories, inodes, strong consistency, system calls). It does this by translating POSIX file operations into S3 API calls. When you read a file, s3fs makes a GET request to S3. When you write, it might buffer data locally and then make PUT requests, or directly stream it. ls becomes a ListBucket API call.
The url parameter is crucial for specifying the S3 endpoint. While s3fs defaults to s3.amazonaws.com, using the correct region endpoint (e.g., s3.us-west-2.amazonaws.com) can significantly improve latency and ensure compatibility with regional S3 features. The passwd_file option tells s3fs where to find your AWS credentials.
The allow_other option, often used when mounting for multiple users, requires adding user_allow_other to /etc/fuse.conf. Without it, only the user who mounted the filesystem can access it.
s3fs handles many S3 nuances. For instance, S3 doesn’t have directories in the traditional sense; they are just prefixes in object keys. s3fs simulates directory creation by creating zero-byte objects with a trailing slash (e.g., my-folder/). When you rmdir, it checks for the existence of this marker object and any actual objects within that "directory" (prefix).
The performance characteristics are important. Reads are generally good, but writes can be slower due to the network latency of S3 API calls and potential buffering. Deletions of many small files can also be inefficient as each deletion is an API call. For heavy write workloads or frequent small file operations, s3fs might not be the best fit.
A common pitfall is forgetting to explicitly set the url for regions other than us-east-1. This can lead to connection errors or unexpected behavior if the default endpoint doesn’t resolve correctly or isn’t the intended target.
When you are mounting a bucket that contains objects with special characters or very long names, s3fs might have trouble directly translating them to valid filenames on your local filesystem. The use_ino option can help with inode management and potentially improve performance by allowing the kernel to cache file metadata more effectively, but it doesn’t directly solve filename translation issues.
The next step is often figuring out how to make these mounts persistent across reboots using /etc/fstab.