nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Apply retention via NetApp REST API throws error "File is not retained by SnapLock."

mthomas

Our current implementation for archiving files in NetApp ONTAP consists of two steps:

Copy the physical file via SFTP.
Set the retention via NetApp SDK (Java bindings).

We want to change our implementation and use the REST API for setting the retention with the same two-step approach:

Copy the physical file via SFTP.
Set the retention via NetApp REST API.

In this case setting the retention does not work and we get this error in the response:

{

"error": {

"message": "File is not retained by SnapLock.",

"code": "13762576"

}

After some try&error we noticed that for files which already had a retention set via the NetApp SDK (old way) we could use the REST API (new way) to set the new retention. So the error seems to be limited to new files for which there was not retention set via the NetApp SDK.

In both cases we use exactly the same environment (NetApp 9.12).

Does someone have any hints as to why this error occurs? Is this approach not supported with the REST API?

Find more posts tagged with

ONTAP REST APIs

Accepted answers

mthomas

Update: In the meantime I got the information that the necessary change in NetApp to fix the mentioned issue will be available in the following listed patches. It will mean, then you have one of this patch in place it is not necessary anymore to use the cluster admin instead of the vadmin to set retention time or to use a autocommit retention.

The patches will come in the next months. But please see, if the change is really included in the patch you must check again. The list documents a planning status.

9.16. P0
9.15. P1
9.14 P3
9.13 P8

All comments

mthomas

Supplement: We also tried archiving a file via the REST API instead of copying it via SFTP in the first step. Even though this was successful (we could read the archived file via REST API) setting the retention for this file was not possible.

This makes us think this is a generic issue with setting the retention via REST API.

mthomas

Info: A support ticket has been created for this issue, see http://mysupport.netapp.com/site/cases/mine/2009783571

I'll let you know when the solution is known.

steiner

Could you provide a snippet of the REST API you're calling to do the commit? Also, have you considered autocommit, where you don't need to invoke SnapLock at all? The file just commits for the required time after being written? Obviously that wouldn't work if you use different retention times, I was only wondering if you'd considered it.

mthomas

As you assumed, we want to write custom, different retention times, so autocommit isn't an option for us, but thanks for pointing out this option.

Here are the exact commands which were copied to the terminal and executed + screenshot from this execution.

# create the file using REST-API (for the purpose of this example, normally we use SFTP to upload files) 
curl -u <user>:<user pwd> --insecure -X POST https://<svm domain name>/api/storage/volumes/cfd95da7-1405-11ee-93ec-005056b823df/files/%2Farchive%2Funittest%2Farchive-92074866-ee1d-45ca-acc9-c02d6773b349%2F000%2F000%2F000%2F001%2F%2F018 -H  "accept: application/json" -H  "Content-Type: multipart/form-data" --form "file=the data to be written to the new file. Current-date is 2023-10=09"

# positive verification that the file was really uploaded and can be read
curl -u <user>:<user pwd> --insecure -X GET https://<svm domain name>/api/storage/volumes/cfd95da7-1405-11ee-93ec-005056b823df/files/%2Farchive%2Funittest%2Farchive-92074866-ee1d-45ca-acc9-c02d6773b349%2F000%2F000%2F000%2F001%2F%2F018?byte_offset=0&length=100 -H "Accept: multipart/form-data"

# failed attempt to set the retention
curl -u <user>:<user pwd> --insecure https://<svm domain name>/api/storage/snaplock/file/cfd95da7-1405-11ee-93ec-005056b823df/%2Farchive%2Funittest%2Farchive-92074866-ee1d-45ca-acc9-c02d6773b349%2F000%2F000%2F000%2F001%2F%2F018 -H  "accept: application/json" -X PATCH -H  "Content-Type: application/json" -d "{  \"expiry_time\": \"2023-10-15T13:11:39+02:00\"}"

mthomas

The patches will come in the next months. But please see, if the change is really included in the patch you must check again. The list documents a planning status.

9.16. P0
9.15. P1
9.14 P3
9.13 P8