Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

Software Development Kit (SDK) and API Discussions

HOSTS authentication problem


I'm trying to use host-based authentication (h

osts.equiv), but it's failing. I get the error:

"User  does not have capability to invoke API quota-report."


If it's not clear, there are two spaces after 'User', as if it were printing a null username. Sure enough, from the log:

Tue Oct 27 11:44:14 CDT [near19: useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-quota-report'


Am I missing something?



I realize this might be old news to some but, testing on a SIM version 8.0.1, setting the options httpd.admin.hostsequiv.enable to on solved this for me.


Try adding the user name in your code. No need to set password, just the user.

For example, in perl use the following call:

$s->set_admin_user($user, $pw);


Already trying that:

        $s->set_admin_user("root", "");

Same error.

I thought perhaps it was because we do not have a user explicitly specified in our hosts.equiv file, but adding another line which explicitly specifies root doesn't change anything.

I've tried it on two filers, one running 7.2.2 and one running 7.3P6.


Try this code.. it works for me.


Nagendra K


Hmm.... Failed for me, but I did have to make one change, because my test filer doesn't have HTTPS set up. Does it work for you if you use HTTP transport instead of HTTPS?


Yes, it does. I just added the Server IP in /etc/hosts.equiv, then invoked this script without providing user name it worked.

Hosts.equiv file


I tried adding the ip instead of the hostname to the hosts.equiv

file, just in case that was the problem, but got the same result:

<results status="failed" reason="User  does not have capability to invoke API system-get-version." errno="13003"></results>
Failed: User  does not have capability to invoke API system-get-version.

Is there any sort of additional debugging I could enable?


Are logs indicating any errors?

Also, try adding " root" in /etc/hosts.equiv and invoke the script "perl hosts_ontapi_hosts.pl root".



   I am seeing the same problem as the original poster. I have SDK 3.5.1, and I can use the "remsh" command successfully from the same system where the API is failing:

cpafisc8-> sudo remsh cpafisnas1 version
NetApp Release Wed Jun 25 08:55:16 PDT 2008

I have run the script you included (after modifying to HTTP instead of HTTPS) and I get this:

<results status="failed" reason="User  does not have capability to invoke API system-get-version." errno="13003"></results>
Failed: User  does not have capability to invoke API system-get-version.

I have a session logged in to the console and I see this at the time the above failure occurs:

cpafisnas1> Wed Nov  4 16:23:04 PST [cpafisnas1: useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-system-get-version'

Any help would be appreciated... Do I need to have a license for "HTTP"?




Ok, after having found another similar thread (http://communities.netapp.com/thread/4102), I was able to resolve this problem by:

$s->set_admin_user("root", "");

This seems wrong to me as the whole reason for having "HOSTS" style is to use hosts.equiv, but since this is working I'm going to use it.



Its a bug in ONTAP and it seems to be fixed in ONTAP 7.3.2


Is it a bug also that a non-root user can use "LOGIN" type with "root" user and "" password and execute commands?

My script has:

our $s = NaServer->new($filer, 1, 1);
$s->set_admin_user("root", "");

And in the auditlog, I see:

Fri Nov  6 09:55:33 PST [cpafisnas1: HTTPPool04:debug]: root:AUTH:error:Login failed for user root from IP reason "User not authenticated"
Fri Nov  6 09:55:33 PST [cpafisnas1: api_mpool_04:debug]: root:API:in:<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE netapp SYSTEM 'file:/etc/netapp_filer.dtd'><netapp version='1.1' xmlns='http://www.netapp.com/filer/admin'><system-get-version></system-get-version></netapp>

The API authentication is failing and I am still able to execute the command - not good!

The behavior is the same on all of my systems ( and




Your script may not work with 7.2.5 release.

If the host on which you enter the command is a UNIX host, the user name is optional. If you do not specify a user name, you must be root on that host to execute any command.

I think when HOSTS style is set, client doesn't send user credentials to the ONTAP. ONTAP defaults the  username to 'root' if it finds no user credentials sent across from client when hostequiv style authentication is enabled.If a client host name and a username is put in to /etc/hosts.equiv then this default switch is not going to happen.

Let us know if you still see the behaviour after upgrading to 7.3.2


The script is working with BOTH and, however it should be failing when not run by the root user.

The problem I am reporting is that when using the "LOGIN" style with user "root" and a null password, I am able to login even when the script is run as a non-root user. This means that even though my hosts.equiv specifically states "root", other users from that machine can perform functions via the API that they are not authorized to. If you see the auditlog entries from my previous message, you can see that the system is saying authorization failed but then allowing the command to run anyway!

This is has serious security implications...




LOGIN  style means that API requests are going to be authenticated using HTTP Basic  authentication (ie., username and password). It really does not matter how you  logged in to the client and running this script, but what matters is what  credentials you passed in via API request. Filer does not use "/etc/hosts.equiv"  file for authenticating these kind of requests.

To be  specific, for LOGIN style authentication, pass in a valid Filer username and  password to have authentication.


$s->set_admin_user($user,  $pwd);

On the  other hand, for HOSTS style authentication, clients must execute the script  using "root" privilege to bind to any reserved port. Currently, Applications  that use SDK cannot support hosts.equiv style authentication for non-root CLIENT  users for APIs.

Please  let me know if you have any questions.




If you read my previous post carefully, you will see that I have the style set to LOGIN, user set to "root" and password as "" (null). The auditlog clearly shows the authentication failing, but my command still runs! The command should NOT run because authentication has failed. This is a problem...



>> The auditlog clearly shows the authentication failing, but my command  still runs! The command should NOT run because authentication has failed.
>> This is a problem...

This is not a vulnerability issue. Reason below:

When you enable "httpd.admin.hostsequiv.enable" option and sent an API request with LOGIN auth style(in your case user:passwd = root:""), ONTAP first authenticate the user using

HTTP basic authentication ie. using username and password. As this request failed due to password credentials mismatch , it logs an error in the auditlog.
Subsequently, it looks at "httpd.admin.hostsequiv.enable" option, and it did successfully authenticate the request as /etc/hosts.equiv was setup properly for this client.


This most certainly IS a vulnerability!  ANY USER can claim to be root and run commands. That user clearly is NOT root, so it should not be authenticated!

The real user id should be passed through the SDK for this "fallback" authentication method and only allowed if the real user is allowed via hosts.equiv.




A non root user cannot execute API with user input as root. The API will error out, if the user is not a root.

Something like this

Vishal Kulkarni

Member Technical Staff



080-41844244 Direct

9986500905 Mobile




A non root user *IS* running this and there is no error. I am using it right now as my own user with no issues:

cpafisc8-> id
uid=14665(cokm) gid=508(techteam) groups=506(tape),507(usradm),513(taxdart),666(security)

cpafisc8-> cat hello_ontapi.pl

my $VERSION = '1.0';    # Controls the SDK release.

use strict;

use lib '/util/bin/netapp/manage-ontap-sdk-3.5.1/lib/perl/NetApp';
use NaServer;
use Pod::Usage;

die pod2usage(
        verbose => 1
) unless $ARGV[0];

our $filer = $ARGV[0];

our $s = NaServer->new($filer, 1, 1);
$s->set_admin_user("root", "");

our $output = $s->invoke( "system-get-version" );
if ($output->results_errno != 0) {
        our $r = $output->results_reason();
        print "Failed: $r\n";
else {
        our $r = $output->child_get_string( "version" );

        print "$r\n";

cpafisc8-> ./hello_ontapi.pl cpafisnas2
NetApp Release Wed Jun 25 08:55:16 PDT 2008



NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner