We seem to be having trouble proving API access at the simplest level - just a basic CLI test such as "curl -siku "mydomain\userid" "https://mycluster/api/cluster?fields=version"". In every attempt we see error:{"code":"6691623", "message":"User is not authorized." I am authorized - I use the same account every day via system manager but I normally have my account set for SAML, so, seeing the curl with -v invoked returns the usual SAML redirect in the output (when the account as SAML as the auth method), so, I modified that account to use "active directory domain" which is what prompted all this - trying to get a service account to login via domain pw. My question is if SAML is NOT the authentication method then why does the cluster keep trying to redirect like it is? There is nothing in AD that would force SAML, the app has to do that I believe. I setup a special domain account for this API access but we can't get any form of it to successfully authenticate (even to SM) because it appears that "any" login looks to be shot to the provider and the "authentication" setting PER user is almost or entirely ignored. Can someone explain why this would happen? I know SAML messed with AIQUM discovery but this seems wrong. Your first ONTAP REST API call is what I was following to ensure simplicity, negating any code issues from the vendor... We have a monitoring app which previously used a local account on each cluster but this is not preferred, so the domain account method is being tried if you're wondering. I suppose another method is better but doesn't explain why "every" account logging in via curl doesn't just work with a valid pw. thanks
... View more
We are seeing inconsistent behavior between ONTAP REST APIs: The public REST API ("/api/storage/volumes") only returns a subset of RW data volumes. The private CLI REST API ("/api/private/cli/volume") correctly returns the full set. Additionally, the public REST API sometimes throws errors like “SVM not found” after certain records are displayed Expected Behavior The public REST API should return all valid volumes, excluding only system, root, or transient volumes. Impact Monitoring and automation tools (e.g., NetApp Harvest) rely on the public REST API output. Because the API is incomplete and inconsistent, monitoring dashboards and alerts are missing critical volumes. This poses risk to automation workflows that assume complete and accurate API responses. Request Please investigate why the public REST API is returning incomplete volume data and throwing SVM errors, while the private CLI API provides the correct information. We need guidance on whether this is a known limitation, configuration issue, or a bug in ONTAP REST.
... View more
I am automating SSL renewal procedure. I have managed to install the certificate, but after installation I would like to enable it (usually done in CLI in the security ssl cmddir by parsing the -server-enabled true argument) to take over from the certificate currently enabled. These are the endpoints present in the /api/docs: GET /security/certificates POST /security/certificates GET /security/certificates/{uuid} DELETE /security/certificates/{uuid} Can someone help navigating me further to accomplish this? I have without success tried in two different ways to update by trying the PATCH method, although not present in documentation, as well as looking through the docs of svm endpoints.
... View more
Getting below error while trying to call Qtree Rename API. Why is the SVM going in lock status ? PATCH /api/storage/qtrees/9fee2a62-xxxxxxxxxxxxxxx/1025?return_timeout=120 : {"export_policy":{"id":xxxxxxxxxxxx,"name":"default"}} :: Error: This SVM is temporarily locked from changes while recording the configuration baseline. Try again in a few minutes or manually stop configuration replication by running "vserver config-replication pause" and retry the command.
... View more
I am trying to resolve the ActiveIQ Suggestion “The node is not configured to save configuration backups to a remote location.” We don’t really understand why POST is the defaulted method for HTTPS and how we cannot change it to PUT as is explained by the KB article the ActiveIQ Suggestion links us to: The web server to which you are uploading the configuration backup file must have PUT operations enabled for HTTP and POST operations enabled for HTTPS. For more information, see your web server's documentation. The problem we are facing is that Artifactory does not support POST for HTTPS and this is where we are attempting to have our backups land. Artifactory returns a 405 when we attempt to use POST. ::*> system configuration backup upload -node storage-cold-01 -backup storage-cold.8hour.2025-03-20.02_15_00.7z -destination <artifactory link> -rest-method POST Enter the username: <username> Enter the password: Uploading the configuration backup file. Error: command failed: Upload operation of configuration backup file exited with error: Failed to upload configuration backup file "/mroot/etc/backups/config/storage-cold.8hour.2025-03-20.02_15_00.7z" to <artifactory link>. Error: HTTP response code said error : The requested URL returned error: 405. ::*> We are able to use ‘system configuration backup upload’ with ‘-rest-method PUT’. We notice there is no way to adjust the REST method that the scheduled backup uses though. I opened a technical support case regarding this and have been told that I must ask about this in here.
... View more
