incorrect S3 bucket permissions can lead to hard-to-diagnose failures

[cloud_trouble]

I'm not sure if this is a bug or not, but it frustrated me for a while.

For some reason, the default amazon bucket permissions allow for upload, but not download. This can lead to a state where 'tahoe put file' works fine, but 'tahoe get file' fails. In the case where there is only one storage server (S3 bucket), it fails with no shares.

I fixed it by changing the bucket permissions to allow my user to get objects.

[zooko]

Good bug report! Thanks!

[daira]

What was the full error printed by tahoe get? Was there any error information associated with the operation in "Recent operations"? It may be the frontend error reporting that is at fault here rather than the cloud backend (which iirc, would report the error from S3).

[cloud_trouble]

tahoe get URI returns the following error:

Error during GET: 410 Gone
NoSharesError: no shares could be found. Zero shares usually indicates a corrupt URI, or that no servers were connected, but it might also indicate severe corruption. You should perform a filecheck on this object to learn more.

The storage node has an incident report with failures like this:

INFREQUENT try 1 failed: GET object ('shares/vs/vsucnfjdwfgcsd2xn66b37odjy/0',) {} <class 'txaws.s3.exception.S3Error'> ('403', '403 Forbidden', '<?xml version="1.0" encoding="UTF-8"?>\n<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>CB12300BA22D757E</RequestId><HostId>2Xd03pkhv080a3lVXCMSh+EevVAhGrVbjwYOU8EGydzTDNYhkIFwQCzNkYTVFCKp</HostId></Error>')
21:26:12.728 [4110]: Giving up, no retry for ("try 1 failed: GET object ('shares/vs/vsucnfjdwfgcsd2xn66b37odjy/0',) {}", '403', '403 Forbidden', '<?xml version="1.0" encoding="UTF-8"?>\n<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>CB12300BA22D757E</RequestId><HostId>2Xd03pkhv080a3lVXCMSh+EevVAhGrVbjwYOU8EGydzTDNYhkIFwQCzNkYTVFCKp</HostId></Error>')
21:26:12.729 [4111]: WEIRD share SI=vsucnfjdwfgcsd2xn66b37odjy shnum=0 unexpectedly disappeared [INCIDENT-TRIGGER]

[exarkun]

The established line of development on the "cloud backend" branch has been abandoned. This ticket is being closed as part of a batch-ticket cleanup for "cloud backend"-related tickets.

If this is a bug, it is probably genuinely no longer relevant. The "cloud backend" branch is too large and unwieldy to ever be merged into the main line of development (particularly now that the Python 3 porting effort is significantly underway).

If this is a feature, it may be relevant to some future efforts - if they are sufficiently similar to the "cloud backend" effort - but I am still closing it because there are no immediate plans for a new development effort in such a direction.

Tickets related to the "leasedb" are included in this set because the "leasedb" code is in the "cloud backend" branch and fairly well intertwined with the "cloud backend". If there is interest in lease implementation change at some future time then that effort will essentially have to be restarted as well.