Cyberduck Mountain Duck CLI

#8034 closed defect (fixed)

Failure connecting with IAM user

Reported by: joealba Owned by: yla
Priority: normal Milestone: 4.5
Component: s3 Version: 4.4.5
Severity: normal Keywords: s3 windows
Cc: Architecture:
Platform: Windows 7

Description

I have created an IAM profile for an S3 bucket and connected via Cyberduck on OS X, and all works fine there.

However when I attempt to connect via Cyberduck on Windows 7, I am unsuccessful in various ways with different versions:

  • In version 4.4.5, the software appears to hang upon a connection attempt
  • In version 4.4.4, the software connects but is not able to list the files/directories
  • In version 4.3.1, I am able to connect to the bucket and view the bucket/folder contents. I can retrieve files and delete files. However when I attempt to upload a file to a directory within the bucket where I know I have write permissions, I receive an "Access Denied" message.

I've confirmed that I am using the same credentials in the OS X version as the Windows version to make sure it is not an issue with my IAM policy.

Change History (15)

comment:1 Changed on Jun 18, 2014 at 10:18:54 AM by dkocher

Plus attach the file cyberduck.log in the application support directory.

comment:2 Changed on Jun 23, 2014 at 5:51:19 PM by joealba

The complete cyberduck.log (testing with version 4.3.1 on Windows 7) contains only the following:

2014-06-23 13:47:49,789 [background-7] FATAL ch.cyberduck.core.ProtocolFactory - Unknown protocol with identifier gd
Last edited on Jun 26, 2014 at 1:50:51 PM by dkocher (previous) (diff)

comment:3 Changed on Jun 26, 2014 at 1:51:07 PM by dkocher

  • Owner changed from dkocher to yla

comment:4 Changed on Jun 26, 2014 at 2:57:53 PM by joealba

Here is a sample IAM policy to assist with your testing. Cyberduck on OSX works as expected based with this policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1394548390000",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/*",
        "arn:aws:s3:::happy-test-bucket"
      ]
    },
    {
      "Sid": "Stmt1394548390001",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/downloads/*"
      ]
    },
    {
      "Sid": "Stmt1394548390002",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/uploads/*"
      ]
    }
  ]
}

comment:5 Changed on Jun 28, 2014 at 6:30:53 AM by dkocher

  • Milestone set to 4.5

comment:6 Changed on Jul 4, 2014 at 1:52:46 PM by dkocher

  • Summary changed from S3 connection fails on Windows to Failure connecting with IAM user

comment:7 Changed on Jul 4, 2014 at 1:53:15 PM by dkocher

If the cause of the issue is the IAM policy, you should get the same results on both OS X and Windows.

comment:8 Changed on Jul 4, 2014 at 1:56:16 PM by dkocher

  • Milestone 4.5 deleted

comment:9 Changed on Jul 10, 2014 at 3:24:13 PM by joealba

Since OS X works fine and Windows does not, I do not believe that the cause of the issue is the IAM policy. I documented the IAM policy here to assist with debugging.

comment:10 Changed on Jul 15, 2014 at 2:54:48 PM by dkocher

  • Milestone set to 4.5
  • Resolution set to worksforme
  • Status changed from new to closed

I have tried to replicate this issue with the same IAM policy and couldn't reproduce any connection failure running the current snapshot build on Windows.

comment:11 Changed on Jul 15, 2014 at 4:01:59 PM by dkocher

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I have found that attempting to upload to a path with no permissions in a bucket that is not in us-east-1 will lead to a broken pipe failure (#7621) instead of the proper access denied failure.

comment:12 Changed on Jul 15, 2014 at 4:04:01 PM by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

Fail fast with Expect: 100-continue header for PUT requests in r14903.

comment:13 Changed on Jul 15, 2014 at 4:18:22 PM by dkocher

The upload with this policy to /uploads/* may also file for large objects if we query for incompleted multipart transfers with a GET request and the uploads request parameter.

comment:14 Changed on Jul 15, 2014 at 8:28:26 PM by joealba

I tried the snapshot today, and it worked correctly.

I did need to download the Microsoft Visual C++ 2010 Redistributable Package to get the snapshot to work, as I initially received a "msvcr100.dll is missing" error.

comment:15 Changed on Jul 15, 2014 at 8:49:10 PM by dkocher

For IAM policies restricting access to certain paths, the blog entry Grant access to user-specific folders in an Amazon S3 bucket is a good read.

Note: See TracTickets for help on using tickets.
swiss made software