Container filter not possible to remove
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
In the Container list, when you set filter e.g., State[]=Exited. Then, you delete the exited container(s). Now, you can not uncheck State[]=Exited filter.
Expected Behavior
Filter resets when not applicable or visible even if not applicable.
Actual Behavior
The filter does not display applied settings when it's no longer applicable to data, so it's unable to remove such.
Steps to Reproduce
- Go to Containers
- Create and stop a container (optional)
- Filter
State=Exited - Delete exited container(s)
- Unable to uncheck
State=Exited
Portainer logs or screenshots
Set filter.
Delete stopped containers, unable to remove filter:
Portainer version
2.22.0
Portainer Edition
Community Edition (CE)
Platform and Version
Docker Swarm 20.10.5
OS and Architecture
Debian 5.10
Browser
Google Chrome 129.0.6668.90
What command did you use to deploy Portainer?
portainer:
image: portainer/portainer-ce:2.22.0
command: -H tcp://tasks.agent:9001 --tlsskipverify
deploy:
labels:
portainer: portainer
mode: replicated
replicas: 1
update_config:
delay: 10s
restart_policy:
delay: 30s
max_attempts: 10
window: 120s
placement:
max_replicas_per_node: 1
constraints: [ node.role == manager ]
resources:
limits:
memory: 280m
environment:
GOMEMLIMIT: "200MiB"
volumes:
- portainer_data:/data
networks:
- portainer
ports:
- target: 9000
published: 9000
protocol: tcp
mode: host
- target: 8000
published: 8000
protocol: tcp
### Additional Information
_No response_
Thanks @trejjam I just tested and confirmed.
internal: BE-11301
Hello 👋🏼
Do you have an ETQA for the fix please? as its quite a problem
@mhzawadi, no ETA at this stage.
Still there on Community Edition 2.27.1 LTS
+1 - issue still present
this one is annoying ... should be a simple fix and quick fix. I know there are many other priority things in hand but a small a quick fix shouldn't take a lot of time.
+1 Any workaround how to remove active filter?
+1 Any workaround how to remove active filter?
The only thing that works for me, is to delete all cookies and reload the page
+1 Any workaround how to remove active filter?
The only thing that works for me, is to delete all cookies and reload the page
Sadly, it doesn't work on 2.30.1 STS. I removed all cookies and did a hard reload with an empty cache in Chrome.
I also have this issue. Please find a solution or add a way to clear all filters.
In Firefox, if you go to DevTools, localStorage you can delete the key "portainer.datatable_settings_containers" and it will remove the filter
In Firefox, if you go to DevTools, localStorage you can delete the key "portainer.datatable_settings_containers" and it will remove the filter
This worked, thank you @PoKeRGT
Sadly, I can confirm that this annoying issue is still present in the recently released Portainer 2.33.0 LTS version.
@Nick-Portainer any updates on fixing this in the current LTS? Is a bit of a shame that this bug is so long standing without a fix (since October 2024!). 😢
Sadly, I can confirm that this annoying issue is still present in the recently released Portainer 2.33.0 LTS version.
@Nick-Portainer any updates on fixing this in the current LTS? Is a bit of a shame that this bug is so long standing without a fix (since October 2024!). 😢
Just upgraded to 2.33.0 and it works for me 🤔
Sadly, I can confirm that this annoying issue is still present in the recently released Portainer 2.33.0 LTS version.
@Nick-Portainer any updates on fixing this in the current LTS? Is a bit of a shame that this bug is so long standing without a fix (since October 2024!). 😢
Agree with @mrhackcz. This issue appears to be fixed in 2.33.0.
Mmhh.. this is how I tested it. I have a local Docker Desktop instance running.
So first, launch a brand new fresh Portainer:
$ docker run --rm -it -p 19000:9000 -p 19443:9443 -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer-ce:2.33.0
After starting up, go to https://localhost:19443/ and create an admin account as instructed. Then just click on "Get started" to use the local Docker socket instance.
Start and stop a couple of containers to have something in the Containers view:
$ docker run -it alpine
/ # exit
At this point this is the view:
Now, use the state filter to select the "exited" containers. Notice the filters being active:
Now, select all the filtered containers (one in this example) and delete them in bulk:
After removing all the "exited" containers, the filter remains active for the "exited" status but it no longer appears as a selectable option (because there are no more containers with the "exited" status), and it is impossible to deselect and clear the filter now:
At this point, there is no way to clear the filter except cleaning the browser data for Portainer, or creating another container with an "exited" status so the option re-appears in the filter menu and it can be deselected.
I just did this again to write this issue, so I'm confident the issue is NOT resolved in 2.33.0.
@hhromic try turning on the "running" filter and turning it off again. The filter should then be disabled. I think deleting all the containers for a given filter is probably a bit of an edge case. Curious if just enabling all the filters and disabling them again will disable the filter. If not, then I guess it's only partially resolved.
Edit: further testing shows you're right @hhromic. it's partially resolved, but still not fully.
Hi,
Also have the issue: during maintenance, I've a few containers that I have to stop. When my host is rebooted, I sort the containers that are stopped (exited), but once they are started, it's not possible to remove the filter anymore. I have to select explicitly "healthy and running" to display them all. How convenient ! 😏
A year later, and this is still present as of 2.33.2 LTS, I spotted it when I added a filter of STARTING, while I had a slow startup of a container.
https://github.com/portainer/portainer/issues/12323#issuecomment-2415543815
Thanks @trejjam I just tested and confirmed.
internal: BE-11301
Today is officially the one year anniversary of the internal issue creation. 😢 I wonder how come the paying customers do not complain about such an evident bug.