Unable to close channel in a track

My team member is getting an error during attempting to close a track on a channel

Your account lacks permission to close channels for this snap. Make sure the logged in account has upload permissions on '2.4/candidate' in series '16'.

I cloud close it properly. I’m looking for some method to manage that ACL in the collaboration UX in the online dashboard but I’m missing how I can manage these permission. Is there something I can do to check permissions on these things and enable more of the team to participate?


Hello @rick_h,

Snap collaborators should be allowed to close channels, in any track (all the channels are in a track, even if it’s latest).

What snap is this? And who is the team member?

Please note that LP team membership does not apply within the store, the user has to be listed as an accepted collaborator.

Regards, Natalia.

This is for the Juju snap and the user is hmlanigan. She’s been able to make changes to which revisions are in the latest track in the past, but hit this error on the 2.4 track when I asked her to close the candidate channel.

Hi folks,

I see the channel 2.4/candidate is now closed, maybe @rick_h did it? In any case, I think the problem is that snapcraft was being invoked incorrectly, a problem we have seen before.

TL;DR it was probably called like:

snapcraft close 2.4/candidate

(omitting the snap name). The correct invocation would be:

snapcraft close juju 2.4/candidate

The error message template makes this evident; the “2.4/candidate” string was substituted as the snap_name variable, not the channel. The message is like this:

'Your account lacks permission to close channels for this snap. Make '
'sure the logged in account has upload permissions on {snap_name!r} '
'in series {snap_series!r}.'

There is a snapcraft bug about this, because it’s not the first time we see this problem, which can be fixed either by making the error message clearer or by better checking command-line parameters.


  • Daniel
1 Like

Thanks for the feedback. It makes sense now. I agree that the error messaging could be better about the proper arguments in this case.