Skip to content
AnyStorage
Free Download

S3 Network Drive

Map an S3 Bucket as a Network Drive on Windows and macOS

Windows has no native way to mount S3. Map an S3 bucket as a network drive on Windows and macOS through a local WebDAV endpoint, with no FUSE driver.

Turn an S3 bucket into a mapped network drive on Windows or macOS through a local WebDAV endpoint, without installing a kernel driver.

map s3 bucket as network drive, mount s3 as local drive, s3 network drive windows

Windows has never known what S3 is

File Explorer maps SMB shares. It limps through FTP. It mounts WebDAV, awkwardly. Object storage was never on the list: no version of Windows has ever shipped an s3:// handler.

macOS is no better. Finder's Connect to Server dialog accepts smb, afp, ftp, http and https. None of those speak the S3 API.

So when you want to open a bucket file in Photoshop, point an editor at footage in S3, or drag three objects to the desktop, the OS is no help. You end up in aws s3 cp, or writing a script for what should have been a drag.

The usual routes, and what each one costs

  • s3fs-fuse. Mature, free, and it needs FUSE. On macOS that means macFUSE, a kernel extension: on Apple Silicon you drop into reduced security mode, reboot twice, and hope the next OS upgrade leaves it alone.
  • rclone mount. Excellent tool, same FUSE dependency, plus WinFsp on Windows, plus a decision about --vfs-cache-mode before many applications will write to the mount at all.
  • Commercial mount drivers. They work. They also install a filesystem driver, want admin rights, and cost money per machine.

None of that is unreasonable if mounting buckets is your daily job. It is a lot of ceremony when what you wanted was a folder.

Mapping an S3 bucket as a network drive, without a driver

AnyStorage goes around the problem instead of through it. The app talks to S3 over the ordinary S3 API, then re-serves everything you have connected through a local WebDAV server. Both operating systems already understand WebDAV, so the mount uses their own client and nothing lands in the kernel.

The sequence is short. Add the S3 connection and open it once so it actually connects. Then go to Services in the sidebar, pick the WebDAV tab, and start the server. It listens on http://127.0.0.1:3211 by default, the port is editable anywhere in 1–65535, and HTTP Basic auth is always on: username anystorage, password generated as 24 random characters the first time. Both are editable, with copy buttons beside them. Leave the server enabled and it comes back with the app next launch.

Every connection that is currently connected appears as a folder at the WebDAV root, named after the connection. Your bucket is a folder. So is the SFTP box next to it.

macOS

Finder → Go → Connect to Server, or just Cmd+K. Enter http://127.0.0.1:3211, click Connect, choose Registered User, paste the username and password from the app.

Reads stream with HTTP range support: drag the playhead to the middle of a 4 GB video and it pulls the bytes around that point instead of downloading the object first.

Windows

File Explorer → This PC → Map network drive, paste http://127.0.0.1:3211, then supply the credentials.

Two things about the native Windows WebDAV client, up front rather than buried. As of 2026 the WebClient service is deprecated and usually not running, so start it in services.msc first. And Windows refuses HTTP Basic auth by default: set BasicAuthLevel to 2 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters and restart WebClient, or you will meet "The folder you entered does not appear to be valid", System error 67, or 0x80070043. One more: WebClient caps a single transfer at FileSizeLimitInBytes, default 50,000,000 bytes, and anything larger fails with 0x800700DF.

A third-party WebDAV client sidesteps all three. So does moving the file inside AnyStorage.

R2, B2, MinIO, Wasabi, OSS and COS land in the same drive

Cloudflare R2, Backblaze B2, Alibaba Cloud OSS, Tencent COS, Google Cloud Storage and Azure Blob each have their own connection type. MinIO and Wasabi go through the S3 type with a custom endpoint URL and path-style addressing. Twenty types in total, counting Google Drive, OneDrive, Dropbox, WebDAV, FTP and SFTP.

They all become sibling folders under one WebDAV root. The FUSE route gives you a mount and a process per remote; here it is one endpoint and one drive letter, however many buckets.

Scope the keys, and know what a mount is bad at

Connect with credentials scoped to the buckets you need. Anything that reaches that drive letter inherits exactly what the access key can do, so hand it an IAM user restricted to one bucket and one prefix, not your root keys.

Then the limits.

  • The free tier serves WebDAV read-only. Read-write comes with Pro, and even on Pro you can keep it read-only on purpose, which suits a machine that should only pull things out.
  • There is no TLS in the current version. The URL is plain http, which is why we bind to 127.0.0.1 by default. A LAN mode binding 0.0.0.0 exists and the app warns you when you turn it on: Basic auth over plain HTTP is credentials in the clear.
  • After an app restart, a connection shows up under the WebDAV root only after you open it in the app, because connections connect lazily. Connections added later need no restart.
  • You cannot copy directly between two connection folders through the mount, and the top-level folders cannot be renamed or deleted from the WebDAV side.

Last thing. A mapped drive is for working with files, not for moving fifty thousand of them. Migrations and prefix-to-prefix copies belong in the app's transfer view. Save the drive letter for the file you need open right now.