Unable to remove credentials from VeeamZIP jobs ...

[Didi7]

Hello,

I am unable to remove credentials from VeeamZIP jobs? How is that done?

Error:
Credentials are currently in use on at least one object. Continue anyway?

A KB I found did not help.

Strange behaviour!

Regards,
Didi7

[Didi7]

I investigated the complete VBR for these objects but they were nowhere to find for me! A history entry is available, when a VeeamZIP job is finished, but other objects are not available to my knowledge, therefore I am unable to find the object for VeeamZip credentials, for which a share was used.

Do we really need to manually remove those credentials from the SQL database every time?

Regards,
Didi7

[Didi7]

Here is a screenshot of the error ...

http://imgur.com/a/A3ovU

If I try to delete the 'ZZZ9' credential, I get the upper error. It must be from a VeeamZip job, but when the job finishes, the object is no longer visible.

Any ideas?

Regards,
Didi7

[Didi7]

I managed to delete the credentials with ...

SELECT * FROM [Backup.Model.MruList]

DELETE FROM [Backup.Model.MruList] WHERE url = ‘<share path>’

Afterwards, I could remove the credentials as well.

Awkward! Is that the only option?

Regards,
Didi7

[foggy]

Have you tried to change the credentials in VeeamZIP options?

[Didi7]

Hello foggy,

thanks for your input, unfortunately I don't understand how this could help to fix my credential deletion problems.

By mistake I used credentials of the VM and not of the share (for which access was granted anyway) and the problems began.

Regards,
Didi7

[foggy]

If you change the credentials to the correct ones, I believe you will stop seeing this message.

[Antanas26]

What is the current status of this issue? The same behaviour on 9.5.4.2866. As far as I am concerned, it's a bug. If you create VeeamZIP backup and then delete it, the share location (which may not even exist any more!) is still tied to the user credential you selected when performing VeeamZIP.

So I want to know the answer to the OP's question: is altering SQL really the only way to fix this? Really?

[foggy]

Hi Antanas, could you please open a case with our technical support so that our engineers could confirm this behavior (and report the issue to R&D if that's the case)? Thanks!