#2341 closed defect (wontfix)

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

Reported by: cloud_trouble Owned by:
Priority: normal Milestone: undecided
Component: code-storage Version: 1.10.0
Keywords: permissions LeastAuthority.com error cloud Cc: daira
Launchpad Bug:

Description

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.

Change History (5)

comment:1 Changed at 2014-11-25T15:07:04Z by zooko

  • Cc daira added
  • Keywords LeastAuthority.com error cloud added; S3 bucket removed

Good bug report! Thanks!

comment:2 Changed at 2014-11-25T16:29:37Z by 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).

comment:3 Changed at 2014-11-25T17:50:06Z by 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]
Last edited at 2014-11-25T18:05:20Z by zooko (previous) (diff)

comment:4 Changed at 2014-11-27T02:02:15Z by daira

  • Priority changed from minor to normal

comment:5 Changed at 2020-10-30T12:35:44Z by exarkun

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.