Yep, your answer is in the screenshot 🙂 :).
Look at attachments, it says 1. No idea where it is attached to but you cannot remove a package if it is still attached to a machine.
make sure to unattach it (if you assigned it, make sure the user that had the attachments logs out) and then you will see that you can remove it.
If it still sees it as attached it could be that the database is not yet cleaned and thus still thinks it is attached.
What happens if you go to the attachment tab? Or could it be that it is still attached to a package machine maybe?
I'm having the same problem with an Adobe acrobat package. It's not assigned to anyone, I see no attachments, but the system still thinks that there's something attached and doesn't let me delete it. Any pointers on how to clear the "attachment" so I can delete this old package?
If the package is locked by a system that no-longer exists, you will have to put a support request in to have GSS run some ruby rails console commands to delete the package for you.
I would not try this your self, because this could corrupt your AppVol database.
I had the same issue.
I solved it by doing the following:
1. creating a new Application. (I named it TO_DELETE)
2. Moved the application I could not delete to this new application TO_DELETE
3. Wait 1 day
4. Deleted the application TO_DELETE together with the package it contained
Version I am using is App Volumes 4.5 (2111.1)
Funny thing then, VMware support has had my case for about 3-4 weeks and just responded a few days ago that updating to app volumes 2111 would resolve the issue. It appears that you're using this version and still need to wrangle with a fix. I was hoping to upgrade our appvolumes servers this weekend when no one was using them to see if it worked.
thanks for your suggestions, Lieven
I would suggest, if you still are having the deletion issue, to have GSS run the Ruby Rails commands to delete this package. this will confirm that all traces of the this package will be deleted from the database.
@Lievenworkaround is not supported by GSS and we cannot confirm if there is still a possible bug that needs to be repo'd.
I work closely with the AppVolumes VMware engineering team and they want to know of these problems ASAP.
Hey @Micheal_A that's strange because we have the exact same issue and they are stating that it is being checked by by engineering.
I do have another workaround which is not supported, at least that's my guess. Will point out here that I am not a VMware employee and use at your own risk :).
When you run a select * from snapvols command towards the database there is a column there that is called Attachment_count, this holds the info if a snapvol is indeed attached. If you manually change that to 0 you are able to remove the application and it will remove the packages as well.
As a cross check I would also make sure to also use the following
select * from snapvol_attachment where snaopvol_id = <ID of the snapvol>. This should not return any results, otherwise it actually does have an attachment towards some machine but at least you'll know which one it is.
But to me this seems to be a bug in how Appvolumes registrates the attachments in the database. It should normally run a check for every snapvol (which actually is a package) if it still has attachments in the snapvol_attachments table.
I've been having this same issue in our environment as well. If you run Rescan under Inventory > Applications, it should detect that the attachments are gone and will allow you delete the packages. I thought there is a background job that's supposed to clear these but I guess it's broken.
This is still happening in version 2203. The best thing to do is what hermanc01 stated.
In my experience manual refresh will usually fix it. If it does not you can edit the database manually; HOWEVER, proceed with caution so you dont cause yourself a bigger headache.