Troubleshooting
Most first-setup failures against Storm Buckets are one of four connection
settings, or a known limitation in the client. Check the settings, then the
client list, then send it in.
Connection settings
| Setting | Value |
|---|---|
| Endpoint | https://alpha.buckets.stormdevelopments.ca |
| Region | storm |
| Addressing style | Path-style |
| Access key and secret | From the control panel |
Wrong region
SigV4 signs the region into every request, so a wrong region fails the
signature rather than the operation. You get HTTP 400 and the error names the
scope the server expected. Read the error, it prints the value to use.
The two values that show up wrong most often are us-east-1, which many
clients ship as their default, and alpha, which is the cluster name.
Endpoint format
Some clients reject a fully qualified URL and want a bare hostname. If
https://alpha.buckets.stormdevelopments.ca is rejected or fails to connect,
try alpha.buckets.stormdevelopments.ca with no scheme.
Addressing style
Path-style only. In rclone that is force_path_style = true.
Virtual-hosted addressing is not supported and is not planned. It puts the
bucket name in the hostname, which only works when bucket names are unique
across the whole service. Storm's are not.
Known client limitations
Software here works against S3 generally but has a limitation Storm cannot fix
from the server side. Workarounds are listed where one exists.
MSP360
no workaroundOffers an S3-compatible connection type with no region field, and signs every
request as us-east-1. Reproduced on Windows against the alpha cluster.
Pointing the client at an alternate endpoint hostname does not change the
signed region. A client that gives you no way to set the region does not
support arbitrary S3 endpoints, whatever the connection type is called. No
server-side fix is possible and there is no client-side workaround.
KopiaUI
workaroundRejects a fully qualified endpoint. Enter the hostname on its own with no
https:// prefix.
rclone 1.60.1
fixed in 1.74.4rclone mount fails to apply modification times and returns
NoSuchKey: Key not found with HTTP 404. Reproduced on Debian 13.6 against
rclone v1.60.1-DEV, the build Debian ships. Fixed upstream in rclone 1.74.4.
Your data is not affected. The object writes correctly and only the
modification time call fails. Install rclone from upstream rather than the
distribution package.
Not supported
Storage runs on Garage, which implements neither object versioning nor object
lock. Upstream is building both. Tracking issue
Deuxfleurs/garage#166.
Object versioning
not implemented| Call | Result |
|---|---|
PutBucketVersioning |
501 NotImplemented |
ListObjectVersions |
501 NotImplemented |
GetBucketVersioning |
200 with an empty configuration, which most SDKs read as unversioned |
GetObject or HeadObject with versionId |
200, current object, parameter ignored |
Object lock
not implemented| Call | Result |
|---|---|
PutObjectLockConfiguration |
501 NotImplemented |
GetObjectLockConfiguration |
501 NotImplemented |
PutObjectRetention |
501 NotImplemented |
PutObjectLegalHold |
501 NotImplemented |
Every value returns the current object, including a version id from an earlier
write, a well-formed id that never existed, and garbage. No read response
carries x-amz-version-id, so nothing tells the client its parameter was
dropped.
PUT responses do carry x-amz-version-id. A client that records those ids on
write and asks for one on restore gets today's object back with a 200. If you
are backing up here with a version-aware client, do not rely on version ids for
restore. Use distinct keys per snapshot.
Sending in something not listed
Use Feedback in the control panel. Include the client and its version, the
exact error text, and your config with keys redacted.