eEKAS-managed SMB with S3 WORM

Familiar file access with object-level retention

Users work with standard SMB clients while eEKAS stores closed files directly as S3 objects and applies the bucket’s COMPLIANCE retention. No S3 keys are required for SMB users.

How it works See the GUI

Available with euroNAS eEKAS

SMB 2 and SMB 3 clientsFamiliar file and folder access for authorised users

↓

Movable IP Group and SMB gatewayOne service address follows the gateway during failover

↓

S3 bucket with COMPLIANCE retentionClosed files become protected object versions

One namespace, two access models

Files are written directly into protected S3 storage

This is not a scheduled export or a second archive copy. The SMB gateway presents the selected S3 bucket directly as a share, while the S3 layer enforces object retention.

Select a protected bucket

Define the bucket’s default COMPLIANCE retention before creating the gateway.

Create the SMB gateway

Assign the bucket, share name and movable service IP in the eEKAS GUI.

Assign share access

Grant SMB users or groups read/write or read-only permissions without issuing S3 keys.

Write and retain

When a file is closed, its protected S3 object version cannot be overwritten, renamed or deleted during retention.

Why this matters

Bring WORM retention to ordinary file workflows

No client-side S3 integrationUsers access the archive through normal SMB clients and do not need S3 credentials.

S3-enforced COMPLIANCE retentionThe object layer prevents protected versions from being shortened or deleted before their retention date.

Independent permissionsSMB share permissions remain separate from optional S3 API credentials.

Service movement without a new addressThe IP Group keeps the SMB gateway and service address together during failover.

Protection behaviour

Retention is deliberately different from a normal working share

Protected through SMB

After a file is closed, SMB prevents overwrite, rename and deletion while the object’s retention is active.

Protected at the S3 layer

COMPLIANCE mode prevents a protected object version from being shortened or deleted before its retention date.

Direct S3 access stays optional

Applications can receive separate S3 credentials when required. Their permissions and the handling of versions or delete markers must be planned carefully.

A delete marker does not erase a retained version. It may hide an object in an ordinary listing, which is why direct S3 credentials should only be issued when the service design requires them.

Suitable workloads

Designed for completed records, not continuously changing application data

Good fit

Archive-style file workflows

Records, evidence, completed documents, reports, exports, media deliverables and other write-once or write-few content.

Use a normal file share

Frequently modified working data

Database files, applications that repeatedly modify data in place, workloads requiring byte-range locking, and users who must routinely rename retained files.

Plan names and folders before ingestion. Retention intentionally restricts reorganising protected files. Expiry permits deletion but does not automatically remove objects.

eEKAS in action

Configure the bucket, gateway and permissions in the GUI

The full workflow is exposed in the administrative interface without requiring command-line prerequisites.

Layered resilience

WORM retention protects object versions—not the entire service

Retention

Prevents premature alteration or deletion of protected object versions.

Replication

Provides another site or copy, with asynchronous behaviour and a defined recovery procedure.

Backup

Preserves independent recovery generations outside the live namespace.

Security

Protects accounts, credentials, clients and administrative access from misuse.

Make protected S3 storage accessible to ordinary file users

Review retention, identity, failover, recovery and application behaviour before enabling the service.

Discuss your use case

SMB, S3, Object Lock and WORM address different parts of the service design. Retention is not a substitute for backup, replication, malware controls, identity protection or a tested recovery process. Supported behaviour depends on the qualified euroNAS version and architecture.