Why you can't FTP or mount into S3-compatible object storage

It looks like a file server. It isn't one

A bucket full of objects, arranged under folder-like prefixes and browsable in a UI, looks enough like a shared drive that it's a reasonable assumption to try mounting it, or connecting to it over FTP the way you would a traditional file server. That assumption doesn't hold, and it's one of the most common points of confusion for anyone new to object storage. Object storage was never built as a filesystem with a network protocol bolted on. It's built as an API from the ground up, and the bucket browser you see in a management console is a UI convenience layered on top of that API, not evidence that a filesystem is underneath it.

Why the underlying model is different

A real filesystem, whether local or mounted over something like NFS or CIFS, lets you open a file, seek to a specific byte offset, write a small change, and close it, touching only the part of the file that changed. FTP and SFTP work in that same file-oriented world. Object storage doesn't work that way. You replace an object, you don't edit it: you PUT an object to upload it, you GET it to download it, you list objects, you delete objects. Range reads and multipart uploads exist, but neither makes a bucket a filesystem, because there's still no protocol-level concept of opening an object and rewriting three bytes in the middle of it. That's a deliberate architectural choice, not a missing feature, it's what lets object storage scale the way it does across huge numbers of objects and huge amounts of data.

FTP, SFTP, NFS, and CIFS are all filesystem-oriented protocols built around that open-seek-write model. Object storage's API speaks a fundamentally different language, so those protocols simply don't apply to it, not because of a missing setting, but because the two models don't map onto each other.

How you actually work with object storage

Instead of a file-server protocol, you talk to object storage through S3-compatible tools and libraries built for exactly this API:

• The AWS CLI, pointed at your provider's own S3 endpoint rather than Amazon's, works against any S3-compatible service, Worldstream's included.
• rclone, a general-purpose sync tool that understands S3 and a long list of other storage backends, useful for bulk transfers and mirroring.
• SDKs such as boto3 for Python, or equivalents in other languages, for building object storage calls directly into an application.

All of these speak the same underlying API. See Object Storage: CLI and SDK reference for concrete setup examples.

FUSE-based mounting: a convenience layer, not a filesystem

Tools exist, generally built on FUSE (Filesystem in Userspace), that make an S3-compatible bucket appear as a mounted filesystem so you can browse it with ordinary file tools. These are genuinely useful for casual browsing or for scripts that expect a filesystem interface. What they don't change is what's happening underneath: every file operation you perform against that mount still gets translated into an API call against a whole object. Opening a large file and appending a small amount of data to it, something a real filesystem handles cheaply, typically means the tool re-uploads the whole object behind the scenes. For that reason, FUSE-based mounts generally aren't recommended for performance-sensitive workloads or anything with a heavy write pattern, an application doing lots of small writes will feel that translation layer directly. They're a convenience for people, not a substitute for using the API properly in an application.