2014-08-21 09:06 AM
I wrote a script using the SDK a few months ago. It's using 'HOSTS' as the auth style, with the transport_style of HTTPS. The intent was to load the snapmirror data from all of our file servers and for most of them it works just fine. I just setup two new filers and am receiving this error:
Warning: Error were encountered on this run!
Warning:User does not have capability to invoke API snapmirror-get-status. for file server deadpool
and on the console:
Thu Aug 21 11:44:31 EDT [deadpool:useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-snapmirror-get-status'
Now the script is run from a host that has root access via rsh (and ssh FWIW) to the file server, and is run as root. Sure enough this is failing on both of the new hosts (these are running 8.2.1P2 if it matters). I did a diff on the options between this filer and a working filer and didn't see anything related to httpd or auth.
Now I also have 3 or 4 file server running 8.1 that return a similar message:
Warning:User XXX does not have capability to invoke API snapmirror-get-status. for file server bucket
Now in this case the user XXX is the account we use the the RSA from the service processor. Again this is run as root from a root host, no where in the code am I using the XXX account (I even added a set_admin_user('root') as a test but no difference).
What am I missing?
Solved! SEE THE SOLUTION
2014-10-25 04:34 AM
Hi Richard - no you're not the only one. And "you're not alone" in hitting this error also. We're hitting it on ONTAP 8.1.3P1D6. Same application works perfect against 7.3.2. Seems 8.1+ may be where this started. We've not tested any versions in between these though. Have found someone else experiencing it as early as March 2013 at this thread: http://community.netapp.com/t5/Software-Development-Kit-SDK-and-API-Discussions/ontapi-HOSTS-style-connection-problem/td-p/60100 but no word on whether that one was resolved. Very keen to know if you've progressed from your situation above?
2014-10-25 06:46 AM
Thanks for the response...good to know I'm not the only one! I have not found a way to fix this. I've done some testing but so far have had no luck in solving the problem. I actually have a 7-mode cluster runing 8.1.4P1 where one head works all the time and the other fails. I've gone through the 'options' and configs on both machines but can find no differences. I will say i have not had any problem with 8.0 OnTap, only a few 8.1 machines. I've also noticed it failes on most of our 8.2 machines as well. I was thinking about opening a support case in regards to this. If I can't get the SDK working on all the machines then I'm afraid we'll have to go back to using rsh/ssh to gather the information we need.
2014-10-25 06:55 AM
Hey thanks for the update. In our case we cannot go lower than 8.1.x as part of what we're doing with the API is SnapLock calls (file-set-retention & file-get-retention) and SL is supported from 8.1 only, after the 7.3.x series.
2014-10-26 11:04 PM
Hey, BTW: can I check what version of the NetApp SDK you're using? We've had a hint that this may be part of the issue (a mismatch between SDK version and ONTAP version).
2014-10-27 10:24 AM
I know it's bad form to reply to my own post, but I just downloaded and tested SDK 5.2.2 with the same results. The filers that failed before still fail.
2014-10-28 03:53 AM
OK, so you strike the error even when using completely up-to-date SDK. Our application is built with SDK 3.5p1, but apart from that we can generate the error using apitest from SDK 5.1. So I'm still leaning towards the problem being in the ONTAP-side.
2015-02-13 06:11 AM
Just thought I'd update the thread that this is still going on, though I see much less of it than I used to. I have still have two NetApps (running 8.1.4P5 7Mode) that routinely have a problem with this. What's most frustrating is that one API call will work and the next will fail (and sometimes subsequent calls will work). I tried opening a case on this but was basically told 'we don't support your code'. Which is fine, I get that but it fails with NetApp code as well. Oh well.