How to Set Up an S3 External Storage Backend in ownCloud 10

ownCloud Server 10 can mount an Amazon S3 bucket as a secondary storage location through the External Storage Support app. To set it up, enable external storage, add an Amazon S3 mount in the administrator storage settings, enter the bucket and access credentials, and confirm that ownCloud reports the mount as ready. This keeps the bucket available in users’ Files view; it does not move ownCloud’s primary data directory to S3.

This guide covers the S3 external storage backend in ownCloud 10. It applies to Amazon S3 and may also work with S3-compatible services when their endpoint, region, and addressing options match the provider’s requirements. Provider compatibility can vary, so verify those values with the storage provider before making the mount available to users.

External S3 storage or primary storage?

An external S3 mount adds a bucket to the ownCloud virtual file system as an additional folder. Users can access it alongside files in their normal ownCloud storage, subject to the mount’s permissions. The separate S3 Primary Object Storage app is a different deployment choice: it changes where ownCloud stores primary file contents and has additional setup and migration implications. Follow this guide only if you want a secondary mount.

Before starting, confirm that your ownCloud Server 10 installation is supported and updated for your environment, that the server can make outbound HTTPS connections to the S3 endpoint, and that you have administrator access. You will need the bucket name, an access key and secret key accepted by the provider, and—if using a compatible service—the correct endpoint, region, and path-style setting.

1. Prepare the bucket and credentials

Create or select the bucket in the storage provider’s console. For Amazon S3, choose the intended AWS Region and review the bucket’s access controls, encryption, lifecycle rules, and backup or retention needs. A bucket is not a substitute for an independent backup plan.

Use credentials dedicated to this ownCloud mount and limit them to the bucket and actions needed for normal file access. Avoid using root-account access keys. AWS recommends avoiding long-term access keys where temporary credentials are practical; where the ownCloud setup requires an access-key pair, protect the secret and follow your organization’s credential rotation policy. Store the secret securely because many providers display it only when the key is created. Do not paste credentials into tickets, screenshots, shell history, or this article’s example.

Ensure that network rules, DNS, and TLS inspection policies allow the ownCloud server to reach the provider. If you use a private or self-signed certificate for a compatible endpoint, import its certificate into ownCloud’s trusted certificate store as required by the external-storage documentation. Do not turn off TLS verification to work around a certificate error.

2. Enable External Storage Support

Sign in to ownCloud with an administrator account. Open Settings > Apps, locate External Storage Support, and enable the app if it is not already active. Then open Settings > Admin > Storage (the exact menu wording can vary slightly by ownCloud 10 release and theme) and confirm that external storage configuration is available.

External Storage Support provides secondary mounts. ownCloud’s administrator documentation says the mount is automatically saved once required fields are filled. A green status indicator means the configured storage is ready; a red or yellow indicator means ownCloud could not connect or validate the configuration, so do not treat the mount as usable yet.

3. Add an Amazon S3 mount

In the administrator storage settings, use Add storage and select Amazon S3. Enter a folder name for the mount point—the name users will see in their Files list. Then enter the S3 access key, secret key, and the bucket name exactly as provided. Keep the secret field private and avoid screen sharing while it is visible.

For a standard AWS S3 bucket, start with the provider’s normal endpoint and region behavior. Enable SSL so requests use HTTPS. For an S3-compatible service, fill in the hostname, port, and region values required by that service. Use the service’s documented endpoint rather than guessing a URL from the bucket name.

When should you enable path-style addressing?

Path-style addressing changes requests from a bucket-specific hostname to a service hostname with the bucket in the URL path. ownCloud’s S3 backend documentation notes that it is generally not needed for Amazon S3 and may not work with newer Amazon data centers; it can be useful with some non-Amazon endpoints where virtual-host DNS routing is unavailable. Follow the compatible provider’s instructions. If the mount fails, check the endpoint and addressing mode together instead of changing several settings at once.

4. Restrict who can use the mount

In Available for, choose the ownCloud users or groups that should see the S3 folder. An administrator-level mount is available to all users by default unless restricted. Give access only to the intended audience, especially when the bucket contains shared, regulated, or operational data.

Review the mount options after the row appears. Depending on the configuration and ownCloud release, options can include read-only access, previews, encryption integration, filesystem checks, and whether sharing is enabled. Sharing on external mount points is disabled by default in the documented configuration; enable it only if users should be able to share those files through ownCloud and the organization’s policy permits it.

5. Verify the connection with a controlled test

Wait for the status icon beside the mount. A green indicator is the first success signal, but it is not a complete data-path test. Sign in as a user who is included in Available for, open Files, and confirm that the mount folder appears. Upload a small non-sensitive test file, open or download it, rename it if that operation is part of the intended workflow, and delete it only if your test policy allows deletion. Confirm the resulting object in the provider’s console or audit logs.

Repeat the read test as a user who is not assigned to the mount. That account should not gain access just because the mount was created. If the mount is intended to be read-only, verify that a write attempt is blocked. Record the endpoint, region, mount name, intended groups, and credential owner in your operations documentation without recording the secret itself.

Troubleshooting a red or unavailable mount

• Authentication error: confirm that the access key and secret belong together, are active, and are allowed to access the bucket. Replace the key through your credential process if it may have been exposed.
• Bucket or permission error: check the bucket name, region, and provider policy. The identity may need additional bucket-level permissions for the operations you are testing.
• Connection timeout: check outbound firewall rules, DNS resolution, proxy configuration, and whether the ownCloud host can reach the provider endpoint over HTTPS.
• TLS or certificate error: verify the hostname and certificate chain. For private certificates, import the trusted certificate using ownCloud’s documented procedure rather than disabling validation.
• Compatible service only: confirm the endpoint hostname, port, region string, and path-style setting against that provider’s documentation. These values are provider-specific.
• Mount remains unavailable after a correction: ownCloud documentation says an external-storage connection issue can remain marked unavailable for ten minutes; click the status icon or reload the Admin page to trigger another check.

Important limitation: files added directly to S3

For S3 and compatible filesystems, ownCloud 10.15 documentation says occ files:scan cannot rescan manually added files. The same documentation warns that ownCloud may not always detect remote changes made outside ownCloud, particularly deep in a folder hierarchy. For dependable file visibility and metadata, perform writes and changes through ownCloud whenever possible. If an external process must write to the bucket, test visibility and consistency for your exact backend and release before relying on that workflow; do not assume that a routine POSIX file scan will repair it.

Also be careful when changing or removing a production mount. ownCloud notes that changing or removing an external storage configuration does not automatically remove its old metadata entries from the database. Plan the change, verify access and backups, and consult the release-specific documentation before cleanup. Avoid deleting the mount as a troubleshooting experiment when users already rely on it.

Configuration checklist

• External Storage Support is enabled.
• The selected backend is Amazon S3 and the mount folder name is clear.
• The bucket, region, endpoint, and any path-style setting match the provider.
• HTTPS is enabled and the server trusts the endpoint certificate.
• The key is protected and limited to the required bucket access.
• Only intended users and groups can access the mount.
• A permitted user can see the folder and complete the required read/write test.
• The team understands that direct external S3 writes may not be detected or rescannable through files:scan.

Official documentation

• ownCloud Server 10.15 External Storage Configuration
• ownCloud Amazon S3 backend configuration notes
• ownCloud occ external-storage commands and backend identifiers
• AWS guidance for securing access keys
• AWS overview of creating an S3 bucket

Documentation checked October 6, 2026. ownCloud’s 10.15 External Storage Configuration page remains the version-specific reference for app behavior and limitations; the dedicated S3 page is linked from ownCloud’s later documentation because the 10.15 S3 page currently returns a not-found response. UI labels and compatible-provider settings can differ by release.