Hello @pma 

This is odd and most likely an issue with a entry being held in the CSDB. 

In the future if you can avoid recreating things with the same name it would always be best. 

I think a support ticket is needed to confirm that there is nothing associated to the wrong library 

They will need to look into the CSDB to confirm before the deletion.

Kind regards

Albert Williams

@pma , has this been resolved? As Albert suggested, please do not perform any deletion since the backend storage is same. Would also suggest to go the ticket route.

Hi,

not solved, i’ve opened a case two weeks ago, no news until now, dev team is looking at this...

Hi @pma 

I hope you raised a support case and now the issue has been fixed.

Regards,

Wasim

Hello Team,

Can you please advise the case number and I will follow up on it.

Kind regards

Albert Williams

Hi @Albert Williams ,

I owned the case and the issue was fixed.

Regards,

Wasim

yes, case fixed by Wasim, very helpfull, thanks

@pma 

Just to help future people who might find this thread can you advise the solution if it was simple enough? 

Can you also please make sure to make the thread as answered.

Kind regards

Albert Williams

Hi,

The only way to solve this was with a support case being raised.

The support team had to generate a unlock code for access to the java console, only then it was possible to perform the following actions (on the command center console this was not possible to perform):

1. Unlocked the Java console.
2. Removed the CS DR SP, primary copy compliance lock.
3. Deleted the job ID:46.
4. Deleted the old library
5. On the CS DR secondary copy policy, added the datapath with the new library.
6. Started the Auxcopy and it was completed successfully.
7. Renamed the library name.