All topics

Access Keys and S3 Clients

NAS Reborn speaks the standard S3 protocol, so ordinary S3 tools work with it. Access is deliberately simple: no users, no permissions matrix, just access keys.

One rule

A request is allowed if it reads from a public folder, or if it carries a valid signature from one of your access keys that reaches that folder. That is the entire access model. A new key reaches everything, so the first reason to create several is revocation: give each client its own labeled key, and you can cut one client off later without touching the others.

Scoping a key

A key can also be narrowed to part of the tree. On the key's screen, turn All folders off and tick the folders it may sign for. The list starts with everything that exists right now, so switching it off takes nothing away on the spot; from then on a folder created later stays out until you tick it too.

What a key cannot reach simply is not there for it. The folder answers 404 NoSuchBucket, it is missing from a bucket listing, and creating a bucket of that name is refused, so a scoped key cannot make a folder it would then be unable to see. Nothing says "denied", because a refusal would confirm the folder exists.

Scoping is not part of the Pro unlock. It only ever narrows a credential, so it is available to every key on every tier.

Managing keys

S3 Files: one tap

S3 Files, from the same developer, puts S3 buckets in the Files app and Finder, and NAS Reborn configures it without any copy-pasting. In a folder's detail screen, tap Add to S3 Files… and the share sheet takes it from there: open it in S3 Files on the same device, or AirDrop it to your iPad or Mac.

The credentials never travel in the shared file; they move through iCloud Keychain, end-to-end encrypted, which is why both devices must be signed into the same iCloud account with iCloud Keychain enabled. The handoff is valid for 24 hours and works exactly once. NAS Reborn keeps a dedicated key labeled "S3 Files" for this, so revoking that one key unpairs S3 Files and nothing else.

rclone

The server is path-style, so the bucket name goes in the path, not the hostname. A working rclone configuration:

[nasreborn]
type = s3
provider = Other
endpoint = https://yourserver.nas2.dk
access_key_id = YOUR_KEY_ID
secret_access_key = YOUR_SECRET
force_path_style = true
region = us-east-1

Then rclone ls nasreborn:photos lists a folder, and rclone sync ~/photos nasreborn:photos mirrors one, which also makes rclone a fine scheduled backup of the server from any computer.

Cyberduck and other tools

In Cyberduck choose an S3 connection, set the server to your hostname on port 443, and enter a key ID and secret. Most S3 clients work the same way; if there is a path-style or "virtual host style" option, choose path-style. Multipart uploads work, so large files are fine.

Sharing single files

To hand someone one file from a private folder, use a presigned link: a URL that grants access to exactly that file until it expires, no key and no account needed on the receiving end. The server honors presigned links generated by standard S3 tools, such as Cyberduck's Share command or rclone link.