This document describes the use and selected implementation considerations of EFS Object Storage, a new feature that provides S3 access to data stored on EFS.

Overview

More and more applications use the S3 protocol instead of POSIX APIs to interact with data storage. In response to this, EditShare Storage gets a new feature in 2026.3.0: S3 read-write access to media spaces.

At the moment, S3 access is available over LAN or over VPN.

Basic usage guide

Role configuration

To enable S3 access to your data, please first set up the EFS Object Storage role on one of the servers using EditShare Role Assistant. Make sure that your network is configured in a way that allows traffic between the selected server (on port 7480) and the workstations/3rd party servers that need S3 access.

Adding access keys

Access Keys and the associated secret access keys are required to access the EFS storage via the S3 protocol, existing editshare user credentials in the form of usernames and password are not used here though analogous to what's needed.

Open the Users tab in EFS Control and select a user that you would like to access the data using the S3 protocol. In the right pane, choose the right-most tab (). 

EFS Object Storage access keys tab before any keys are created.

Then, click the plus sign in the bottom right to create a new pair of keys. A dialog box with the access key and the secret key appears.

Make sure to copy the secret key - it is the only time it is displayed. 

EFS Object Storage access keys tab after creating a key.

Accessing data in a media space

The data is served on port 7480 of the machine that plays the EFS Object Storage role in your cluster. You can access it using your favorite S3 client, e.g. awscli, the official command-line client from Amazon:

# List all the buckets, i.e. media spaces, available to the user bearing the provided keys.
$ AWS_ACCESS_KEY_ID="<access_key>" AWS_SECRET_ACCESS_KEY="<secret key>" \
  aws --endpoint-url http://"<hostname>:"7480 s3 ls
my_media

# Upload a file.
$ AWS_ACCESS_KEY_ID="<access_key>" AWS_SECRET_ACCESS_KEY="<secret key>" \
  aws --endpoint-url http://"<hostname>:"7480 s3 cp my_video.mov s3:/my_media/

Note that buckets use the raw media space name (in its S3 compliant form, see Naming & paths below), and do not include an appended _1

Key details

If a user has at least one access key assigned, all of their media spaces are available over the S3 protocol. Each media space is available as a separate bucket.

Naming & paths

To conform with the basic AWS S3 bucket naming rules, the media space names are turned into bucket names by making all the characters lowercase and turning spaces into dashes. Object keys map to directories and files by splitting the key on /.

When uploading an object whose key has multiple forward slashes, all the intermediate directories are created automatically. Using a POSIX filesystem as the backend storage results in possible error situations not possible in real S3. Trying to upload to a key whose prefix corresponds to a regular file results in an ObjectParentIsFile error. Trying to overwrite an object corresponding to a directory results in an ExistingObjectIsDirectory error.

Permissions

Each access key is mapped to a specific EditShare user. The actions permitted for an authorized S3 request are strictly limited by the EFS-level permissions of that associated user. For example, if a user has read-write permissions for a media space, the request can both read from and write to the corresponding bucket. If the user has read-only access, the request is restricted to reading. All the keys associated with a single user come with the same access rights.

New buckets cannot be created directly via S3 requests; instead, a new media space must be created within EditShare. Similarly, deleting a bucket via S3 requests is forbidden.

Caveats

Media space types

Unmanaged media spaces are strongly recommended. The other media spaces can be safely used for read-only workflows (no uploads via S3).
 

HTTPS

At the moment, only http traffic is supported.
 

Etags

Etags are a hash of the object; one can query it to quickly determine if an object has changed without retrieving the whole object. Workflows relying on ETag values do not work correctly. The objects created out of S3 protocol (via EFS) have an empty ETag, the objects uploaded with S3 protocol do have an ETag. Note though that when the latter are modified using POSIX requests (changing a file via a filesystem mount), the ETag will not be reset.

Other metadata attributes such as the size and last modified timestamp are correctly returned.