Buckets in LibreS3 can be accessed in three ways:
A direct access to the object, which works even if the bucket name is not DNS compatible.
Requires that bucket names are DNS compatible and a DNS/hosts entry for each bucket or a wildcard DNS record (see 3.1)
Equivalent to bucket.example.net.libres3.example.com.
The client should send a Host: bucket.example.net header, which usually requires a CNAME DNS entry, see 3.1. Requires that bucket names are DNS compatible, and that you use your FQDN as the bucket name, for example:
s3cmd mb s3://bucket.example.net
The latter can be useful for public buckets, see 6.4.
LibreS3 supports streaming files from SX by downloading blocks as they are needed (streaming a large file begins as soon as the first batch of blocks is downloaded by LibreS3).
It is also possible to begin streaming a file from an arbitrary position, and retrieve less than the entire file, i.e. range requests.
This works both for authenticated (s3cmd get --continue) and public requests (wget --continue), see 6.5.
Since version 1.1 LibreS3 uses the Apache/NCSA Combined Log Format for its access.log file, for example:
The first line is an example for an authenticated request, and the second line is an example for an anonymous request (using directory indexing according to the referer).
The format is:
User-Agent of the client (not all S3 clients send a user-agent, for example s3cmd doesn’t)
Access.log entries are written asynchronously, after the entire reply body is sent to the client.
s3cmd ls s3:// shows only the buckets that are owned by your user, what is consistent with S3’s behaviour. In case you have access to some buckets in read or write mode and would like to use them with s3cmd or other clients, you can enable listing of all accessible buckets by adding the following to libres3.conf and restarting LibreS3:
LibreS3 supports IPv6 communication with SX version 1.2 or newer (note that an SX node can have either an IPv4 or an IPv6 public address, but not both at the same time). LibreS3 can be reached either by IPv4 or IPv6, depending on how your DNS wildcard record is set up, and whether your S3 client and OS support IPv6.
Each volume in SX has a maximum size (its quota). There is no equivalent concept in S3, thus you need to specify the default volume size (and replica count) for buckets created through S3 in libres3.conf using the volume_size field. This is done automatically if you used libres3_setup to configure LibreS3.
In case a new file would exceed the SX volume’s quota, LibreS3 should report an HTTP 413 error. The quota errors will be reported for both normal and multipart uploads, however in the case of multipart ones, the quota error will only be reported after all parts have been uploaded to LibreS3.
LibreS3 creates an internal volume for each user to store the parts uploaded during a multipart upload. This volume’s name is prefixed by libres3- and is created with the size specified in the volume_size field and replica count 1. You have to ensure that the size is sufficient to hold all in-progress (and interrupted) multipart uploads for a user, otherwise one may run out of space during multipart upload even if the destination volume has plenty of space available.
Interrupted multipart uploads are not automatically removed (because one can resume by providing the upload ID), to clean them first run s3cmd multipart on each bucket in turn to find out the objects and upload IDs, and s3cmd abortmp on each upload ID in turn to actually delete it: