Cloud Containers / NAS Gateway
A Cloud Container maps one bucket on external object storage to a QuantaStor Network Share, so NFS and SMB clients read and write cloud storage as an ordinary file share. This page covers the cloud provider model, creating and importing containers, the local cache, what a cloud-backed share can and cannot do, and how Backup Policies use a Cloud Container as an auto-tiering target.
Everything on this page lives under the Cloud Integration tab. The tab can be hidden per user role, so it is not necessarily visible to every administrator -- see Security Configuration. Creating, importing and enabling a container are also licence-checked operations.
| Section | Purpose |
|---|---|
| How a Cloud Container works | What is created on the appliance and in the cloud |
| Cloud providers, locations and credentials | Which providers are offered, and how to authenticate to one |
| Adding a private or S3-compatible provider | Pointing QuantaStor at your own object storage |
| Creating and importing containers | Create a new bucket, or attach one that already exists |
| Cloud Container cache settings | Cache modes, where the cache lives, and its size limit |
| The Network Share side | What a share of type cloud can and cannot do |
| Auto-tiering with Backup Policies | Freeing local space and leaving stub files behind |
| Container operations | Enable, Disable, Detach, Import, Rescan, Repair |
| Ownership, grids and DR | Which appliance owns a container, and what happens on failover |
| Provider setup guides | Per-provider steps for creating access keys |
| Troubleshooting | Common failure modes and what to check |
Object storage is a good fit for data that is written once and read rarely. Reads come back over the internet, so they are slow compared with a local pool, and most providers charge for egress -- size the local cache and the access pattern accordingly.
How a Cloud Container works
QuantaStor mounts the bucket with rclone, a FUSE filesystem, and then presents that mount as a Network Share:
- The bucket is mounted at
/mnt/cloud-containers/qs-container-<container-id>. - That mount is bind-mounted onto
/export/<container-name>, which is the path NFS exports and SMB shares. - A Network Share of type
cloudis created automatically and points at the same path. It has no Storage Pool, because there is no local storage behind it. - The container's ID is derived from its storage URL, so re-importing the same bucket later produces the same container ID. That is what makes an import a true recovery rather than a new object.
The Storage URL column shows a string of the form s3c://<endpoint>:443/<bucket> (or s3://<bucket> when the endpoint is exactly s3.amazonaws.com). This is an identity and display string, not a protocol the client speaks -- clients speak NFS and SMB, and the appliance speaks S3 to the provider.
There is no systemd unit and no /etc/fstab entry for a Cloud Container. The service re-establishes every mount it owns on a two-minute sweep, which is how containers come back after a reboot and how a mount that was lost is recovered without operator action.
Container and provider records are grid-wide, so a container created on one appliance is visible from any appliance in the grid, but only its owning appliance mounts it.
Cloud providers, locations and credentials
Three objects sit between an account at a provider and a working container:
- A Cloud Provider is the service itself. Eight are built in, and you can add your own.
- A Cloud Provider Location is one endpoint of that provider -- a region, or a public/private/direct variant of a region. Locations for the built-in providers are pre-populated.
- Cloud Provider Credentials are one account's access key and secret key at one provider. A container references a credential and a location.
Storage classes are pre-populated per provider in the same way, and are offered on the container dialogs.
Providers offered
| Provider | Pre-populated locations | Pre-populated storage classes | Extra credential fields |
|---|---|---|---|
| Amazon S3 | 20 | 8 | -- |
| Backblaze B2 | 1 | -- | -- |
| Dropbox | 1 | -- | Generated Token |
| Google Cloud Storage | 21 | 5 | Project ID/Token, Auth File |
| Google Drive | 1 | -- | Project ID/Token, Auth File |
| IBM Cloud Object Storage (COS) | 69 | 4 | -- |
| Microsoft Azure Blob | 1 | -- | -- |
| Wasabi S3 | 3 | 3 | -- |
List the current set on your own appliance rather than trusting the counts above, which are a snapshot of a fresh install:
qs cloud-provider-list qs cloud-provider-location-list qs cloud-provider-storage-class-list
Those are qs cloud-provider-list, qs cloud-provider-location-list and qs cloud-provider-storage-class-list. Where a provider has no storage classes of its own the container dialogs offer a single Default entry, which sends no storage class and lets the provider apply its own default.
QuantaStor Scale-Out Object, built on Ceph RGW, is reached the same way: add it as a provider using its S3 endpoint. See QuantaStor Scale-Out Object and Ceph Object Storage.
Adding credentials
| Field | Notes |
|---|---|
| Cloud Provider | Required. Lists every Cloud Provider known to the grid, built-in and user-added. |
| Username/Access Key | The access key from the provider. Some providers call this a username. |
| Secret Access/API Key | Required. The secret key, entered masked; the eye button reveals it. |
| Secret Access/API Key (Confirm) | Required, and must match. |
| Project ID/Token | Shown only for Google Cloud Storage, Google Drive and Dropbox. For Dropbox the same field is labelled Generated Token. When it is shown it is required. |
| Auth File | Shown only for Google Cloud Storage and Google Drive. The path on the appliance to the service-account JSON file supplied by the provider. When it is shown it is required. |
Every other provider hides both of the last two fields, so the dialog is three fields plus the provider picker.
The credential's display name is generated for you as provider name followed by the access key in parentheses -- for example Amazon S3 (aAbBcCdDeEfF01234567). That name is what the container dialogs and the Cloud Container grid show in their Cloud Provider column, so the access key is visible wherever a credential is referenced. Bear that in mind before sharing a screenshot of the Cloud Integration tab.
The CLI equivalent is qs cloud-provider-credentials-add:
qs cloud-provider-credentials-add --provider="Amazon S3" \
--access-key=aAbBcCdDeEfF01234567 \
--secret-key=aAbBcCdDeEfF0123456789aAbBcCdDeEfF012345
There is no modify operation for a credential. To rotate a key, add the new credential, move the containers onto it by detaching and re-importing them, then remove the old one.
Where credentials are stored
Credentials are held in the configuration database and are also written to /root/.config/rclone/rclone.conf, because that is the file the mount reads. In both places the secret is stored in the clear -- what protects it is filesystem permissions: the /root/.config/rclone directory is mode 0700 and readable only by root.
The API and the CLI mask the secret. qs cloud-provider-credentials-list and qs cloud-provider-credentials-get both print ******** for the password field; the access key is not masked, because it is not a secret and it is already part of the credential's name.
Treat a QuantaStor appliance that holds cloud credentials as being in scope for whatever key-rotation policy covers the object storage account, and restrict who holds a QuantaStor administrator role with modify rights -- see Security Configuration.
Removing credentials, locations and providers
None of the three removes any data from the cloud, and none of them removes a container. Removing a credential first disables every container that uses it, which takes those shares offline; the containers can be brought back by adding an equivalent credential and enabling them again. Both the Remove Credentials and Remove Provider dialogs say so on the dialog itself.
Removing a credential or a location is also available from the CLI as qs cloud-provider-credentials-remove and qs cloud-provider-location-remove. Removing a provider is a web interface and API operation only -- there is no cloud-provider-remove CLI command.
Adding a private or S3-compatible provider
Use this for object storage that is not one of the eight built-ins -- a QuantaStor Scale-Out Object cluster, a MinIO or Ceph RGW deployment, or any other S3-compatible service. The dialog creates the provider, its first location and one credential in a single step. There is no provider-type selector: the entry is treated as S3-compatible, and the only credential fields offered are an access key and a secret key.
| Fieldset | Field | Default | Notes |
|---|---|---|---|
| Provider Information | Name | s3-provider-N |
Required. Alphanumerics and -_. only.
|
| Description | object storage |
Free text. | |
| Supports Ceph Cloud Tiering | unchecked | Marks the provider as usable to back a Ceph cloud storage class. Leave it clear unless you are configuring Ceph RGW cloud tiering, which is a separate feature from Cloud Containers. | |
| Location Information | Name | Default |
Required. The friendly name shown in the Location/Region picker. |
| Tag | default |
Required. The region tag, such as sjc01. Providers that have no notion of a region can keep default.
| |
| End-point | https://x.x.x.x:7480 |
Required. The FQDN or URL of the S3 endpoint. Replace the placeholder; port 7480 is the Ceph RGW default. | |
| Cloud Storage Provider Account Credentials | Access Key | empty | Required. Some providers call this a username. |
| Secret Key | empty | Required. | |
| Secret Access Key (Confirm) | empty | Required, and must match. |
To add a second endpoint to a provider that already exists, use Add Provider Location instead. Its three location fields are the same, and start empty; changing the provider selection clears them. The CLI equivalents are qs cloud-provider-add and qs cloud-provider-location-add.
Storage classes for a custom provider can be added with qs cloud-provider-storage-class-add; there is no dialog for it.
Creating and importing containers
There are two ways to get a container, and they differ in one respect: whether the bucket already exists.
Create Cloud Storage Container
This creates a new bucket at the provider and maps it. On OK, QuantaStor creates the bucket, makes the mount point, mounts it, and brings up the Network Share.
| Field | Default | Notes |
|---|---|---|
| Name | nas-bucket-N |
Required, and becomes the bucket name. 3 to 63 characters, ASCII letters, digits and the hyphen only, and it may not start with a hyphen. For any endpoint other than s3.amazonaws.com the name is lower-cased for you. It must also be unique at the provider, not just on the appliance.
|
| Description | empty | Free text. It is copied into the Network Share's description. |
| Attach To System | the appliance you are connected to | The grid member that will own and mount the container. Changing it re-loads the cache settings below from that appliance's defaults. |
| Cloud Provider | first credential | Required. Despite the label this picker lists credentials, shown as provider (access key). Changing it re-filters the Location/Region and Storage Class pickers to that provider. |
| Location/Region | the provider's default location | Required. Only locations belonging to the selected credential's provider are listed. |
| Storage Class | Default |
Default sends no storage class and lets the provider choose. Otherwise only classes belonging to that provider are listed.
|
| Cloud Container Cache Settings | see below | Seeded from the Attach To System appliance's defaults. |
The dialog refuses to open if no credentials exist ("There are no cloud provider credentials.") or if the grid has no cloud provider locations at all.
Add/Import Cloud Storage Container
Use this to attach a bucket that already exists -- one filled by another tool, or one that belonged to a container you detached earlier. Nothing is created at the provider; the bucket must already be there.
The fields are the same as Create, minus Name and Description, plus:
| Field | Notes |
|---|---|
| Bucket | Required. The picker starts as Click search to scan for available buckets.... The magnifier button scans the provider with the selected credential and location and fills the list; the minus button clears it. If the scan returns nothing the list reads No buckets were discovered.... Changing the credential or the location resets the picker, so scan again after either change. |
Because the container ID is derived from the storage URL, re-importing a bucket that was previously attached to this grid restores the same container object, and any Backup Policy that referenced it keeps working.
The CLI equivalents are qs cloud-container-create and qs cloud-container-add, with qs cloud-container-bucket-scan doing what the magnifier does:
qs cloud-container-bucket-scan --provider-creds="Amazon S3 (aAbBcCdDeEfF01234567)" --location-tag=us-east-1 qs cloud-container-add --provider-creds="Amazon S3 (aAbBcCdDeEfF01234567)" --location=us-east-1 --bucket-name=doctest-archive
Both dialogs always enable NFS on the new container and always use the rclone container type. The older s3ql and s3fs container types are deprecated; if an upgraded appliance still has any, the service raises an alert at start-up asking you to contact support.
Cloud Container cache settings
The Cloud Container Cache Settings fieldset appears on the Create and Import dialogs, and only there. There is no modify dialog for a container, so cache settings are fixed at the moment the container is created or imported -- to change them, detach the container and import it again with the settings you want. The bucket and its contents are unaffected by that round trip.
| Control | Default | Notes |
|---|---|---|
| Cache Mode | from the appliance default, which ships as Write | See the table below. |
| Cache Share | <System> |
<System> puts the cache in /tmp on the appliance's system disk. The picker also lists any Network Share that was created as a Cloud Container cache share.
|
| Unlimited Max Cache Size / Limit for Max Cache Size | Limit, at 8GB |
Radio pair. Selecting Unlimited greys out both the size box and the slider. The slider sets the size as a percentage of 200GB, so its default position of 4% is 8GB. |
A limit must be between 2GB and 200GB; outside that the dialog reports The Max Cache Size value must be between 2GB and 200GB.
Cache modes
| Mode | Behaviour |
|---|---|
| Default | Use the appliance's configured default, which ships as Write. |
| Off | No caching. Reads and writes go straight to the object service. Some file operations are not available in this mode. |
| Min | As Off, except that files opened for read and write are buffered. More compatible than Off and uses very little cache space, but some file operations are still unavailable. |
| Write | Files opened read-only stream directly from the object service with no local copy. Anything opened for write, or for read and write, is staged in the cache first and uploaded afterwards. |
| Full | Reads and writes are both buffered. Data read from the object service is kept in the cache, so a second read of the same file is served locally. Cached files are sparse. |
Write is the shipped default and is the right choice for a share that is mostly written and rarely re-read, such as an archive or a tiering target. Full is the one to pick when clients re-read the same files, since it is the only mode that caches reads -- at the cost of needing cache space proportional to the working set.
What is stored locally
Only the cache, and any auto-tiering stub files. All file data lives in the bucket. Nothing about a Cloud Container consumes Storage Pool capacity unless you deliberately move the cache onto a pool-backed share.
Data is fetched from the cloud when a client opens a file, and in Write mode it is not retained afterwards. Directory listings are treated differently: they are cached for 15 minutes and the remote is polled for changes every 5 minutes, so a file added to the bucket by something other than this appliance can take up to 15 minutes to appear. Rescan flushes that cache immediately.
Moving the cache off the system disk
With the default <System> cache share the cache is in /tmp, on the appliance's system disk. That is fine for light use and a poor idea for a heavily written container: the cache competes with the operating system for space, and when the filesystem fills, writes to the container fail with a no-space error. The only warning you get is the generic boot device low free-space alert, which fires at 25%, 15% and 8% free.
To put the cache on a Storage Pool instead, create a Network Share marked as a cache share and then select it. The share is never exported, must be on a ZFS pool, and cannot be on an HA pool:
qs share-create --name=doctest-cc-cache --pool=pool1 --is-cloud-container-cache=true qs cloud-cache-default-settings-modify --cloud-settings=<settings-id> --cache-share-id=<share-id>
See qs share-create and qs cloud-cache-default-settings-modify. In the web interface the same flag is Use As Cloud Container Cache Share, in the Cloud Container Options fieldset of Create Network Share. It cannot be combined with software encryption on the same share, and the flag cannot be set or cleared afterwards -- the checkbox is disabled in Modify Network Share, so a share is a cache share or it is not, for its whole life.
Appliance-wide cache defaults
Every appliance carries one Cloud Container cache settings object, which is what the Create and Import dialogs pre-load. Read and change it with qs cloud-cache-default-settings-get and qs cloud-cache-default-settings-modify. Changing the defaults does not touch containers that are already mounted -- an existing mount keeps its settings until it is disabled and enabled again, or repaired.
The shipped values come from /opt/osnexus/quantastor/conf/qs_cloudcontainers.conf on the appliance, which is the authoritative reference for the mount arguments and for the handful of per-backend options that have no dialog control at all -- certificate checking for private S3 and Ceph endpoints, and upload concurrency for Azure Blob.
| Setting | Shipped default |
|---|---|
| Cache mode | writes
|
| Directory cache time | 15m
|
| Remote poll interval | 5m
|
| Buffer size | 64M
|
| Cache directory | <system>, i.e. /tmp
|
| Cache maximum age | 1h0m0s
|
| Cache poll interval | 1m0s
|
| Cache maximum size | not set, i.e. unlimited |
(Note: these are the values as shipped; the file on the appliance is authoritative for what your system is actually using.)
When no maximum size is set, nothing bounds the cache by size and entries are evicted by age alone -- items older than the maximum age are reaped on each poll. Between one poll and the next the cache can grow to the size of the write working set, which is the reason the dialog defaults to a limit rather than to unlimited.
A container's share is a Network Share of type cloud. It is created automatically when the container comes online and removed when the container is deleted; you do not create or delete it yourself. Attempting to delete it from the Network Shares view is refused with Deleting a shadow network share for a Cloud container is not supported. To delete this share, you must delete the Cloud Storage container.
The share is created with permissive defaults: owner and group nobody/nogroup, mode rwxrwxrwx, POSIX ACLs, both NFS and SMB enabled, and client access granted to *. Restrict the client access list and set up user access before putting anything in the container, exactly as you would for any other share.
Because there is no pool and no snapshot capability behind it, a large part of the Network Share feature set does not apply. The web interface hides or greys these out rather than letting them fail:
| Not available on a cloud share | Notes |
|---|---|
| Snapshots | Refused with Network Share '<name>' is a Cloud Container. Cannot snapshot the share. |
| Long-term snapshot retention | The whole Snapshot Settings tab of the Backup Policy dialogs greys out when the selected share is a cloud share. The dialog states the rule itself: Long Term Retention Rules only apply to ZFS and CephFS share types. |
| Snapshot holds | Supported only on shares from ZFS pools. |
| Space and file quotas, user and group quotas | Supported only on ZFS and CephFS shares. |
| Read-only marking | ZFS shares only. |
| Clone, rollback, restore | Cloud shares are filtered out of the pickers. |
| Remote replication, synchronous and asynchronous | Refused with Operation is unsupported for cloud containers or nested shares. |
| Configuration templates | Not offered. |
| Encryption and key management | Refused for all five key operations. |
| Global namespaces | Refused with Network Share (<name>) associated with Cloud Containers cannot be added to namespaces. |
| Share move | Refused with Network Share '<name>' is Cloud Container. Cannot move share. |
| Sub-shares and aliases | Refused with Network Share '<name>' is of type 'cloud', sub-share/alias '<name>' creation is currently not supported on it. |
| ZFS tunables -- compression, dedup, record size, sync, copies | Silently ignored; there is no ZFS dataset to set them on. Advanced Settings, Ownership Settings and Permissions Mask are all disabled in Modify Network Share for a cloud share. |
| Immutability, ransomware detection, auto-copy policies | Skipped for cloud shares. |
| Per-user and per-group usage reporting | Skipped; the grid shows N/A for physical usage on a cloud share.
|
SMB and NFS serving themselves are fully supported, including SMB client access lists and Active Directory integration.
To take a cloud share offline, disable the container rather than the share -- the share's own Enable and Disable actions resolve to the parent container anyway.
Auto-tiering with Backup Policies
A Backup Policy can use a Cloud Container as its Remote Storage Export, alongside the SMB and NFS options. That is how you move cold data off a pool and into object storage on a schedule.
Select Cloud Container as the Remote Storage Export, then pick the container. The three modes behave as follows with a cloud destination:
| Backup Mode | Direction | What happens |
|---|---|---|
| Copy Files | Outbound | Files are copied into the bucket. The local copies stay. Inbound copies files out of the bucket into the share. |
| Move Files | Outbound | Files are transferred into the bucket and the local copies are freed, with nothing left in their place. Inbound moves them out of the bucket, removing the objects. |
| Auto-tier Files | Outbound only | Files are copied into the bucket, the local copies are freed, and a stub is left in the share in their place. Inbound is greyed out. |
Purging is blocked for both move modes -- there is nothing to purge at a destination you are migrating into.
Stub files
A stub is a symbolic link, created in place of the file it replaced, pointing at the same file inside the Cloud Container's mount -- /mnt/cloud-containers/qs-container-<container-id>/<path>. The link is resolved by the appliance, not by the client, so a client that reads a stub gets the file's contents streamed out of the bucket and never sees the link.
Two things follow from that, and both matter when planning a tiered share:
- Serve tiered shares over SMB. The Samba options that let the server follow a stub out of the share are configured together with snapshot browsing. Disabling snapshot browsing on a tiered share therefore stops the stubs resolving, and clients see broken links.
- NFS clients cannot follow a stub. The link target is an absolute path that exists on the appliance and not on the client, so an NFS client resolving it against its own root gets a file-not-found error. Verified on 6.9.0 by reading a stubbed file over NFSv3: the read fails while the same file read through SMB succeeds. Improving this is tracked in QSTOR-11892.
Stubs are only valid while the container is mounted at that path on that appliance, which is another reason a container has a single owner.
Scheduling and thresholds
Two settings on the policy change how much space a tiering run actually reclaims:
- Stubbing runs at most once a day per policy unless you force it. The transfer happens on every trigger, but the pass that frees local files and writes stubs is rate-limited to one run per day.
--force-remove-tiered=truemakes it run on every trigger; despite the name it removes nothing extra, it only lifts the once-a-day limit. - Set a minimum auto-tier size.
--min-auto-tier-thresholdskips files at or below the given size. Tiering a large number of tiny files is a poor trade -- each one costs a request at the provider and each stub still occupies an inode locally -- and setting the threshold also turns on an extra check that confirms the object is visible through the mount before the local file is freed.
A run reads the live share rather than a point-in-time snapshot of it, so schedule tiering for a quiet period. The service log records which was used, with a line beginning Running backup from ORIGIN. This is tracked in QSTOR-12421.
If the transfer reports any error, the stubbing pass is skipped entirely for that run and nothing local is freed. That is deliberate: it is the guard that stops a partly failed upload from taking local data with it.
With Maintain Logs enabled the per-file logs are written to /var/log/qs/backup-log on the appliance.
Cloud Containers can only ever be a policy destination, never a source. Continuous Data Protection and auto-copy are both refused for a Cloud Container source.
Container operations
All six actions are in the Cloud Container toolbar group, and all six are also on the right-click menu of a container in the tree.
| Action | On the appliance | In the cloud |
|---|---|---|
| Create | Creates the mount point, mounts the bucket, brings up the Network Share | Creates the bucket |
| Import | Same, for a bucket that already exists | Nothing; read-only |
| Enable | Validates the cache directory, mounts the bucket, brings the share online. Optionally on a different grid member, which is how a container is moved between appliances | Nothing |
| Disable | Unmounts the export and the bucket on every grid member and takes the share offline. The container object stays | Nothing |
| Detach | Removes the container object, the share, the export and the mount, on every grid member | Nothing, unless you tick Delete bucket and contents from the cloud |
| Rescan | Invalidates the mount's cached file and directory metadata so out-of-band changes appear immediately | Nothing |
The Enable dialog is two pickers -- Cloud Container and Storage System -- and the Storage System selection follows the container's current owner when you change the container. Point it at a different grid member to move the container there. Disable, Detach and Rescan each take a container.
Repair has no toolbar button and is CLI-only: qs cloud-container-repair. It exists for a mount that has wedged -- the symptom is a transport endpoint error on the export path -- and it force-unmounts and remounts. The container must be disabled first; run against an online container it reports Cloud container is currently online, you must first disable the container before attempting to repair it.
Detach, and what happens to the data
Detaching a container does not delete anything in the cloud. It removes the mapping: the container object, its Network Share, the export and the mount. The bucket and every object in it remain at the provider, and the container can be brought back later with Import.
To destroy the cloud-side data as well, tick Delete bucket and contents from the cloud. The dialog changes its confirmation text when the box is ticked, from Are you sure you want to detach cloud storage container '<name>'? to a message that names the permanent deletion explicitly, so read the confirmation before accepting it.
The same distinction on the CLI is the --delete-cloud-bucket argument to qs cloud-container-delete, which defaults to false:
qs cloud-container-delete --container=doctest-archive # detach; bucket survives qs cloud-container-delete --container=doctest-archive --delete-cloud-bucket=true # bucket and contents destroyed
Deleting a very large bucket can take longer than the default timeout allows. Raise the delete_bucket_timeout setting in the [cloudContainers] section of /etc/quantastor.conf, which ships commented out so the built-in default applies.
Ownership, grids and DR
A container is owned by one appliance -- the one named in Attach To System -- and only that appliance mounts the bucket. Other grid members see the container object and its share but do not serve it.
Enable a container on one appliance at a time. Disable it on its current owner before enabling it elsewhere. Nothing in the product prevents two appliances from mounting the same bucket, and rclone does not coordinate writes between two mounts, so two live mounts of one bucket can lose data.
The single exception is a DR failover, where this is expected and handled: while a failover is active the source appliance and the DR site both hold a mount of the same bucket, so that the DR site can read tiered files while the source is unreachable. Relevance lapses on its own when the replica checkpoints are deactivated, and failback needs no unwind step.
Provider setup guides
Creating the access key and secret key is done at the provider, not in QuantaStor. These pages cover the steps per provider:
- AWS Cloud Integration -- Amazon S3
- Backblaze B2 Cloud Integration -- Backblaze B2
- Dropbox Integration -- Dropbox
- Google Cloud Integration -- Google Cloud Storage and Google Drive
- Microsoft Azure Blob -- Azure Blob
- IBM Cloud Object Storage -- IBM COS
- Ceph Object Storage -- Ceph RGW, including QuantaStor Scale-Out Object
Wasabi S3 uses the same access key and secret key model as Amazon S3.
Troubleshooting
| Symptom | What to check |
|---|---|
| A container will not enable, and the error names blocking files | The mount directory has to be empty. The error names the count and one example file. Remove them and enable the container again. |
| Enable fails with a message about the bucket region | The region check runs a listing before mounting, because a mount with the wrong region succeeds and only fails later on I/O. Confirm the Location/Region matches where the bucket actually lives. |
| Enable fails with a cache directory error | The cache share is gone or is not mounted. If the cache is on a pool-backed share, the pool has to be imported on the owning appliance. |
| The export path returns a transport endpoint error | The FUSE mount has wedged. Disable the container, then run qs cloud-container-repair, then enable it.
|
| A file added to the bucket elsewhere is not visible | Directory metadata is cached for 15 minutes. Run Rescan to flush it. |
| Writes to the container fail with a no-space error | The cache filesystem is full. With the default <System> cache share that is the appliance system disk. Set a max cache size, or move the cache to a pool-backed share.
|
| Tiered files read as broken links | The client is using NFS, or snapshot browsing has been disabled on the share. Serve tiered shares over SMB with snapshot browsing left enabled. |
| A container shows as offline and no alert was raised | There is no alert for a Cloud Container going offline. Monitor container State and State Detail, which carry the reason. |
| A backup or tiering job stopped running and no alert was raised | A failed backup job sets the job state to failed without raising an alert. Monitor the Backup Policies & Jobs view rather than the alert list. |
Two CLI commands are worth knowing for diagnosis: qs cloud-container-get prints the mount point, storage URL, cache settings and state detail for one container, and qs cloud-container-list gives the same at a glance for all of them.
Related pages
- Network Shares -- the share a Cloud Container is presented as
- Backup Policies -- scheduling copy, move and auto-tier jobs to a Cloud Container
- Storage Pools -- where a pool-backed cache share lives
- Security Configuration -- administrator roles and access control
- QuantaStor Scale-Out Object -- using QuantaStor's own object storage as the provider
- QuantaStor CLI Command Reference -- full argument lists for every Cloud Container and Cloud Provider command
Verified against QuantaStor 6.9.0.