Cyberduck Mountain Duck CLI

#9851 closed feature (worksforme)

Interoperability with NetApp StorageGrid Webscale

Reported by: crankbird Owned by: dkocher
Priority: lowest Milestone: 6.0
Component: s3 Version: 5.3.5
Severity: trivial Keywords:
Cc: Architecture:

Description (last modified by crankbird)

Dear mountain duck developers .. I've just tested mountain duck against the NetApp StorageGrid Webscale product

The good news is that it worked perfectly using the S3 protocol handler, I'm planning on testing the Swift interface too, and I've let our services team and other practitioners know, and I've suggested that they use Mountain Duck as a trouble shooting / testing tool.

I know you've probably got higher priority items than verifying functionality against every S3/Swift compliant object store out there, but if you want to do some interoperability testing of your own, NetApp can give you any documentation you might want and a repository for you to test against.

Personally I'd like to see the interoperability confirmed from both sides, because that would make it easier for me to recommend mountain-duck to our enterprise clients as a client based filesystem client (as opposed to using a CIFS / NFS gateway) that has a well defined support infrastructure.

Regards John Martin Director Strategy and Technology - APAC NetApp.

Change History (5)

comment:1 Changed on Feb 15, 2017 at 1:33:06 AM by crankbird

  • Description modified (diff)

comment:2 Changed on Feb 15, 2017 at 9:02:00 AM by dkocher

  • Component changed from core to s3
  • Owner set to dkocher
  • Summary changed from Confirm interoperability with NetApp StorageGrid Webscale to Interoperability with NetApp StorageGrid Webscale

Thanks for your testing. You might be interested to share a connection profile for your customers with some more predefined settings for a bookmark. I have added NetApp to the list of thirdparty S3 providers. If required on can dedicate a wiki page to interoperability with NetApp StorageGrid Webscale.

comment:3 Changed on Feb 15, 2017 at 9:13:50 PM by crankbird


I've begun the process with our product development and QA team, and I've added it to one of my personal projects without a specific completion date. Once I've had more feedback from product operations, or have an ETD for doing something myself, I'll update that in the comments here.

There was another group of interoperability questions with Cyberduck that are being discussed internally that we've discovered during some large scale proof of concept work around things like large multi-part upload timeouts and object vs bucket ACLs.

Would it be correct to assume that Cyberduck and Mountainduck use the same access engine ? If so, does it make sense to add those questions to this ticket, or to open seperate tickets for each question ?

Regards John Martin

comment:4 Changed on Feb 17, 2017 at 2:28:24 PM by dkocher

Mountain Duck uses the same core modules with the protocol implementations. Please open a separate ticket for each issue. If more like a question or something to discuss you can also write to

comment:5 Changed on Mar 6, 2017 at 9:55:57 AM by dkocher

  • Milestone set to 6.0
  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.