portainer
Shelling into container does not always work (depends where link is used)
Before you start please confirm the following.
- [x] Yes, I've searched similar issues on GitHub.
- [x] Yes, I've checked whether this issue is covered in the Portainer documentation or knowledge base.
Problem Description
Sometimes when shelling into a container the request will fail with no user notification that something did fail (a user must use the devtools to see this request failed). Other times it will work, you'll get shell access to the container / task you specified.
Times when it fails the websocket URL looks like this: wss://<REDACTED>/api/websocket/exec?endpointId=<REDACTED>&id=<REDACTED>
times when it works the websocket URL looks like this: wss://<REDACTED>/api/websocket/exec?endpointId=<REDACTED>&id=<REDACTED>&nodeName=<REDACTED>
Expected Behavior
to shell into a container no matter where the link is pressed
Actual Behavior
sometimes the request will fail. suspect incorrect URL generated on links or within javascript scripts / automation
Steps to Reproduce
click the shell into container icon from different locations (container section / stack section / service section etc)
Portainer logs or screenshots
No response
Portainer version
2.30.1
Portainer Edition
Business Edition (BE/EE) with 5NF / 3NF license
Platform and Version
Docker 2.27.1 LTS
OS and Architecture
Alpine Linux 3.21.3
Browser
136.0.7103.92 (Official Build) (64-bit)
What command did you use to deploy Portainer?
shell script which starts up the docker-compose as a swarm service.
updates the service if it is already running.
Additional Information
No response
Hi @kale1d0code, I can't reproduce this. Can you break down the steps that will allow me to attempt to reproduce this as close as your environment?
I'll see if I can catch some recordings maybe a har file of when it happens. I'll have to make sure anything I provide doesn't contain any sensitive information
@kale1d0code, are you always shelling into the same container and does that container have a shell binary (e.g. /bin/sh)? some containers might not contain a shell and will always fail. For example, the Portainer container uses the scratch image and has no shell so it will always fail.
@hookenz Hi good suggestion however these containers do have shells. We run a mix of alpine and Debian containers and I am well versed on having to specify the right one 😅. I have since come across the issue again and have made a HAR file. I do need to review it still for sensitive information however I would like to share this with you.
I will look into making a screen recording as well but I have not made one currently.
To clarify The options to pick what user and shell you want to use shows up fine however upon choosing your options and pressing the connect button. The connection is never made. I need to navigate around through to stacks and drill down to what I want from there.
I'll look into securing logs from the agent maybe? I'm not sure what to look for. We run all our logs through Loki so I'll have a dig through and see what I can find.
@kale1d0code pass it on to @Nick-Portainer. I don't work for Portainer anymore, but I am familiar with that bit of the code as I rewrote parts of the docker side of it.
I just noticed something though. This is invalid: wss:///api/websocket/exec?endpointId=&id= There should be hostname and endpointId in there. Or did you scrub it out for posting here?
Matt