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).
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.
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.
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.
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.
Hi, this is in fact an ONTAP bug that has been previously identified and there is a bugfix release that can be obtained (at least it's available for 8.1.4 - it's version 8.1.4P1D7). Note that the bug is specific to the hosts.equiv auth method. The bug ID is 269652 - the description of which might be only available internally. If you can get hold of that version (8.1.4P1D7) I'd be interested to hear if it fixes your issue.
Richard - Thank you! I looked up the bug and it's public. Looks like it's fixed in lots of later OnTap revisions (include 8.1.4P7) so no need for the 'd' patch release. I don't know if I'll be able to upgrade my two problem children anytime soon, but I have seen intermittent failures on other hosts that will be easier to upgrade.
Yeah see how you go - but if it's still failing then do try the D-path version I mention. IIRC, even though it's marked as being fixed in other versions, it actually got missed from a lot of those versions - hence the D7 patch version was made specially for our customer who was hitting it too many times to bear.
Sorry, forgot to mention that the 8.1.4P1D7 version was only released in November 2014 (or early December), so any version 8.1.x or 8.2.x released earlier (even with later version numbers) will likely *not* be fixed from this bug...