Docker desktop stopped working after upgrading Ubuntu from 23.10 to 24.04

[md-owes]

Description

I upgraded my Ubuntu OS from 23.10 to 24.04 via sudo do-release-upgrade -d command and the upgrade was successful without any issue. However, after the upgrade and system restart, when i start docker desktop, it did not respond to clicking the docker desktop icon via app launcher. Thinking it might be due to system upgrade i decided to uninstall docker desktop 4.29 and reinstalled the same version but still docker desktop was unable to start. I verified the logs located at ~/.docker/desktop/log/host and there were no entries with keyword 'error' or 'fail'. I verified the service docker-desktop was enabled and running via command systemctl --user status docker-desktop but the command systemctl --user status docker gave error "Unit docker.service could not be found".

Reproduce

1. upgrade Ubuntu from any version (i upgraded from 23.10 but i believe it could be any version) to 24.04 via "sudo do-release-upgrade -d"
2. restart system
3. Start docker desktop

Expected behavior

Docker desktop should run with all my images and containers intact

docker version

terminal gets stuck while running this command but docker --version prints the below output 

Docker version 26.1.0, build 9714adc

docker info

terminal gets stuck while running this command

Diagnostics ID

7D75123F-C60D-4C2F-A751-FAC458B49182/20240427092253

Additional Info

No response

[andinianst93]

I have the same problem too. The Docker engine works fine though. It just I can not open the UI.

[wgrs]

Docker Desktop not working for me on Ubuntu 24.04 fresh install

[luiz-fernandoalves]

I freshly installed Ubuntu 24.04, and now Docker Desktop is not launching. I followed the official installation instructions (which worked for me on version 22.04), but it's still not successful.

[raza2022]

Same so I can confirm the official installation was completed successfully, but Docker Desktop is not launching in Ubuntu 24.04

Steps

1. install fresh Ubuntu version 24.04
2. follow the Docker official instructions
3. Launch Docker Desktop

[artshade]

terminal gets stuck while running this command

Have you tried stracing the "stuck" command in order to find out what or when the exact sys-call or loop hangs?

Not to mention Linux and not Windows cases, have you tried not using Docker Desktop at all but marvelous and fairly sufficient CLI or... TUI at least?

[beelzick]

Same error here

[md-owes]

Apologies for tagging but looking for some eyes here asap as my work is completely dependent on it. @christophermclellan, @aiordache, @bsousaa

[ptdatta]

Same issue for me too. If I ran it from /opt/docker-desktop/bin/docker-desktop it say docker desktop starting but it never starts.

[vic-reis]

Seguimos triste, irei tentar instalar a versão 22 do ubunto para ver se é questão de compatibilidade do sistema, pois, a extensão do VSCODE segue com o mesmo erro.

[Arnispl]

I did these steps and now it works fine.

1. Remove the System-Level Mask You need to remove the symbolic link that's masking the service at /etc/systemd/user/. Because this involves system-level changes, you'll need to use sudo:

sudo rm /etc/systemd/user/docker-desktop.service

Reload Systemd

2. After removing the symlink, reload the systemd daemon to apply the changes:

systemctl --user daemon-reload

3.Unmask at the User Level (if still needed) If the service is still showing as masked at your user level, unmask it:

systemctl --user unmask docker-desktop

4. Start Docker Desktop Try starting the Docker Desktop service again:

systemctl --user start docker-desktop

5. Check the Service Status Confirm that the service is active and no longer masked:

systemctl --user status docker-desktop

[Lapakin]

I did these steps and now it works fine.

1. Remove the System-Level Mask
   You need to remove the symbolic link that's masking the service at /etc/systemd/user/. Because this involves system-level changes, you'll need to use sudo:

sudo rm /etc/systemd/user/docker-desktop.service

Reload Systemd 2. After removing the symlink, reload the systemd daemon to apply the changes:

systemctl --user daemon-reload

3.Unmask at the User Level (if still needed) If the service is still showing as masked at your user level, unmask it:

systemctl --user unmask docker-desktop

4. Start Docker Desktop
   Try starting the Docker Desktop service again:

systemctl --user start docker-desktop

5. Check the Service Status
   Confirm that the service is active and no longer masked:

systemctl --user status docker-desktop

Unfortunately, this didn't help me, as the file was not in the folder.

[mayurDayal2000]

Hello, I encountered the same issue with the Docker Desktop GUI not loading. I managed to resolve it by navigating to /opt/docker-desktop/bin in the file system, right-clicking on com.docker.backend, and choosing 'Run'. This got Docker up and running for me. However, it seems to be stuck at the 'starting the Docker engine' loading screen now. Hope this helps anyone else facing the same problem!

[artshade]

Apologies for tagging but looking for some eyes here asap as my work is completely dependent on it. @christophermclellan, @aiordache, @bsousaa

As mentioned above, have you tried stracing to define and locate the issue causer? I don't have such issues, so I - cannot.

[ptdatta]

systemctl --user status docker-desktop

Hey @Arnispl I tried your solution but in my case, it just stuck at the starting stage. I can see the service is running but every docker command is stuck. I tried with docker ps -a

[simon-curtis]

Hello, I encountered the same issue with the Docker Desktop GUI not loading. I managed to resolve it by navigating to /opt/docker-desktop/bin in the file system, right-clicking on com.docker.backend, and choosing 'Run'. This got Docker up and running for me. However, it seems to be stuck at the 'starting the Docker engine' loading screen now. Hope this helps anyone else facing the same problem!

Can confirm this worked for me too. And I am getting the same result, loading screen with no interactivity. Tools like docker compose just hang with no output

$ sudo systemctl is-active docker
active

$ docker info
Client: Docker Engine - Community
 Version:    26.1.0
 Context:    desktop-linux
 Debug Mode: false
//... truncated
Server:
ERROR: Cannot connect to the Docker daemon at unix:///home/simon/.docker/desktop/docker.sock. Is the docker daemon running?

Same output after running sudo systemctl start docker

Tried using sudo dockerd and go this:

$ sudo dockerd
INFO[2024-04-29T20:14:51.791691352+01:00] Starting up
failed to start daemon, ensure docker is not running or delete /var/run/docker.pid: process with PID 2292 is still running

So tried again

$ sudo rm /var/run/docker.pid
$ sudo dockerd
INFO[2024-04-29T20:18:59.472233212+01:00] Starting up
INFO[2024-04-29T20:18:59.472991190+01:00] detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf
failed to start daemon: error while opening volume store metadata database (/var/lib/docker/volumes/metadata.db): timeout

**** Restarted PC

$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-04-29 20:28:07 BST; 1min 49s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 2299 (dockerd)
      Tasks: 18
     Memory: 107.1M (peak: 108.2M)
        CPU: 785ms
     CGroup: /system.slice/docker.service
             └─2299 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Apr 29 20:28:06 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:06.661678638+01:00" level=info msg="Starting up"
Apr 29 20:28:06 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:06.665620700+01:00" level=info msg="detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf"
Apr 29 20:28:06 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:06.744609074+01:00" level=info msg="[graphdriver] using prior storage driver: overlay2"
Apr 29 20:28:06 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:06.748766463+01:00" level=info msg="Loading containers: start."
Apr 29 20:28:07 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:07.234483033+01:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Apr 29 20:28:07 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:07.382076738+01:00" level=info msg="Loading containers: done."
Apr 29 20:28:07 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:07.414289859+01:00" level=info msg="Docker daemon" commit=c8af8eb containerd-snapshotter=false storage-driver=overlay2 version=26.1.0
Apr 29 20:28:07 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:07.414658784+01:00" level=info msg="Daemon has completed initialization"
Apr 29 20:28:07 simon-P330-server dockerd[2299]: time="2024-04-29T20:28:07.505601417+01:00" level=info msg="API listen on /run/docker.sock"
Apr 29 20:28:07 simon-P330-server systemd[1]: Started docker.service - Docker Application Container Engine.

[Spikhalskiy]

Attaching a full journalctl --user -u docker-desktop.service -f log of systemctl --user start docker-desktop on Ubuntu 24.04.

Pieces that look relevant:

Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.040465382Z][com.docker.backend.tasks][E] supervisor detected that task has died with an error: shutdown with exit code 1: docker
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/supervisor/tasks.monitor({0x31a35a8, 0xc00034c000}, {0xc0004bafb0?, 0x2?}, 0xc000c31e10)
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/supervisor/tasks/supervisor.go:73 +0xf3
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/supervisor/tasks.Supervise.func2()
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/supervisor/tasks/supervisor.go:47 +0xce
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/supervisor/tasks.Supervise in goroutine 139
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/supervisor/tasks/supervisor.go:46 +0x1f3
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.040572545Z][com.docker.backend.tasks][I] shutting down 1 tasks
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.040586300Z][com.docker.backend.tasks][I] shutdown group 0/0: [docker]
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.040598472Z][com.docker.backend.tasks][I] all 1 tasks shutdown
Apr 29 15:35:16 workstation com.docker.backend[45615]: 145265-Services.startCLIMetrics: supervising tasks: task failed: shutdown with exit code<INT>: docker
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.040674649Z][com.docker.backend.services][I] CLI metrics failed: supervising tasks: task failed: shutdown with exit code 1: docker

Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.112511919Z][com.docker.backend.electron][E] electron shutdown by signal: trace/breakpoint trap
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/internal/electron.open.func1()
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/internal/electron/electron.go:215 +0x2e7
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/internal/electron.open in goroutine 31
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/internal/electron/electron.go:190 +0x34c
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.122171962Z][com.docker.backend.features][I] unleash client successfully synced with server
Apr 29 15:35:16 workstation com.docker.backend[45615]: [2024-04-29T19:35:16.122776101Z][com.docker.backend.features][E] unleash:  segment does not exist
Apr 29 15:35:16 workstation com.docker.backend[45615]: [common/cmd/com.docker.backend/internal/features.(*debugListener).OnError(0xc0002fa1b0, {0x316eae0, 0xc000526290})
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        common/cmd/com.docker.backend/internal/features/unleashremote.go:107 +0x11e
Apr 29 15:35:16 workstation com.docker.backend[45615]: [github.com/Unleash/unleash-client-go/v3.(*Client).sync(0xc000dea000)
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        github.com/Unleash/unleash-client-go/v3@v3.9.2/client.go:210 +0x388
Apr 29 15:35:16 workstation com.docker.backend[45615]: [created by github.com/Unleash/unleash-client-go/v3.NewClient.func1 in goroutine 581
Apr 29 15:35:16 workstation com.docker.backend[45615]: [        github.com/Unleash/unleash-client-go/v3@v3.9.2/client.go:129 +0x56

docker-dektop-service.log

[Spikhalskiy]

:white_check_mark: I was able to solve this issue with

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like an Electron and Chromium issue https://github.com/electron/electron/issues/41066 and the above workaround was originally suggested in https://github.com/electron/electron/issues/41066#issuecomment-1913509942

UPD: You can create a file /etc/sysctl.d/20-apparmor.conf or /etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent. It's a good idea to remove it when the fix to electron and Docker Desktop is released.

[simon-curtis]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

[artshade]

I was able to solve this issue by running

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like it's an Electron issue electron/electron#41066 and this workaround suggested in electron/electron#41066 (comment)

Related: https://github.com/moby/moby/issues/47480 (rootless (non-dpkg): update docs and dockerd-rootless-setuptool.sh check for Ubuntu 24.04 (kernel.apparmor_restrict_unprivileged_userns)...)

[sebasalas]

I was able to solve this issue by running

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like it's an Electron and Chromium issue electron/electron#41066 and this workaround was suggested in electron/electron#41066 (comment)

It worked for me, thanks!!!

[ptdatta]

Worked for me too thanks.

[luiz-fernandoalves]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

This operation works for me. Thanx !!!

[tuberquia2115]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

Thank you so much !! It's been hours and nothing has solved it and your answer saved me from staying up late

[luiz-fernandoalves]

I followed the instructions and now I can start Docker Desktop without running the commands. However, there is a security issue.

file: /usr/lib/sysctl.d/10-apparmor.conf 

 If it is desired to disable this restriction, it is preferable to create an
 additional file named **/etc/sysctl.d/20-apparmor.conf** which will override this
 current file and sets this value to 0 rather than editing this current file

kernel.apparmor_restrict_unprivileged_userns = 0

[kartikeya-lyzr]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

This resolved my issue as well. Thank you I just hope disabling apparmor_restrict_unprivileged_userns is not a security risk on desktop linux. I was facing the same issue. docker version was getting stuck and opening Docker Desktop did nothing.

[artshade]

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

This resolved my issue as well. Thank you I just hope disabling apparmor_restrict_unprivileged_userns is not a security risk on desktop linux. I was facing the same issue. docker version was getting stuck and opening Docker Desktop did nothing.

Have you checked out references mentioned above?

In a report from Google, 44% of the exploits they saw required unprivileged user namespaces as part of their exploit chain... Therefore, for Ubuntu, we are introducing restricted unprivileged user namespaces, where AppArmor can be used to selectively allow and disallow unprivileged user namespaces. An AppArmor policy is used to selectively control access to unprivileged user namespaces on a per applications basis. As such, unprivileged processes will only be able to create user namespaces if they are confined and have the "userns," rule in their AppArmor profile (or if they have CAP_SYS_ADMIN). Since it is not feasible to create a complete AppArmor profile for most affected applications, we introduced a new default_allow profile mode. While this effectively allows the application to remain unconfined, it also adds a new “userns,” rule to allow it to use unprivileged user namespaces. Source

When specified in this manner, an application that is confined by such an AppArmor profile will be allowed to create new unprivileged user namespaces... ...the new kernel sysctl does place a restriction on unconfined applications, by denying them the ability to create unprivileged user namespaces by default. In this case, a profile which specified the unconfined flag and no additional permissions would be blocked from using unprivileged user namespaces. However, when combined with the userns permission above, an application confined by such a profile would then be allowed to use unprivileged user namespaces and not be confined in any other way. Whilst this does not achieve any meaningful confinement of the application, it does allow such applications to continue to use unprivileged user namespaces and avoids the risk of introducing any regression in functionality through the use of an AppArmor profile that was inadvertently too restrictive. It is suggested that this approach will likely be the most appropriate for the majority of applications that legitimately require the use of unprivileged user namespaces, compared to a complete AppArmor profile. Source

[simon-curtis]

This is very important to point out, thank you. The workaround should only be temporary and used with caution.

On the flip side, the setting kernel.apparmor_restrict_unprivileged_userns=0 is still the default for 23.10 so if you roll back then means exposing yourself to the same exploit. Risk analysis should be done.

[md-owes]

i forgot to provide my update that the below comment fixes the issue and is a kind of workaround. I am good to close the issue as it has unblocked my work. Thanks to all the participants in this thread especially @Spikhalskiy.

✅ I was able to solve this issue with

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like an Electron and Chromium issue electron/electron#41066 and the above workaround was originally suggested in electron/electron#41066 (comment)

[Spikhalskiy]

@md-owes I think a good idea and a common practice is to keep this issue open for tracking and reference purposes until the root cause problem is addressed in Chromium and Docker Desktop is updated accordingly. Otherwise, this issue may look resolved, while the best we have atm is a workaround.

You may mention the existing workaround in the issue description for easier discovery by people who come here for a solution though.

[md-owes]

Now i have started to notice that with the workaround Docker Desktop starts but gets hung up after some period of activity. Ubuntu then asks me to Force Quit docker desktop as it can no longer be used. This behavior has been consistent in my environment. Anyone else facing this issue?

[Spikhalskiy]

@md-owes I don't observe anything like that on my systems, docker looks pretty stable with the workaround. It's likely some other problem.

[md-owes]

Attaching screenshot of the issue which is happening quite a lot since the workaround

[s-andrzejewski]

If you still having issues with this topic uninstall docker engine and docker desktop [go to ubuntu tab].

Then make everything step by step like here https://github.com/docker/desktop-linux/issues/211#issuecomment-2097555794

Voilà! Everything works fine.

[KelvinEuclides]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

can't thank you enough

[KPark612]

I'm able to get it working but if my system reboots I have to do it all over again. Anyone else had this issue?

[simon-curtis]

This is expected. All these commands are doing is temporarily overriding a security setting. You could add a cron job to run it on startup if you want:

How to run scripts on start up?

[Spikhalskiy]

You can create a file /etc/sysctl.d/20-apparmor.conf or /etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent.

But folks, github issue comment section is not the place for general linux or ubuntu questions not directly relevant to the problem report. Please use StackOverflow and other appropriate channels for such discussions.

[MikeMcC399]

See also Ubuntu 24.04 LTS (Noble Numbat) Release Notes > Unprivileged user namespace restrictions

[shavakkar]

✅ I was able to solve this issue with

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like an Electron and Chromium issue electron/electron#41066 and the above workaround was originally suggested in electron/electron#41066 (comment)

UPD: You can create a file /etc/sysctl.d/20-apparmor.conf or /etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent. It's a good idea to remove it when the fix to electron and Docker Desktop is released.

Does this also Works for fedora??? Im struck with this same problem in fedora... Please... kindly help me.

[baokhuu-phoenix]

Worked for me, just running systemctl --user restart docker-desktop after:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ systemctl --user restart docker-desktop

and docker deskop UI pops up immediately. Thank you!

Worked for me, thank you.

[joshchernoff]

Am I the only one who feel that just using kernel.apparmor_restrict_unprivileged_userns=0 carte blanche is.. I don't know... a bad idea? I assume there was a reason Ubuntu added https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces :facepalm: hey screw it, lets just disable our firewalls too open up localhost and let it rip!

In a report from Google, 44% of the exploits they saw required unprivileged user namespaces as part of their exploit chain.

Also worth reading. https://docs.docker.com/engine/security/apparmor/

and also. https://github.com/docker/desktop-linux/issues/211

[Spikhalskiy]

@joshchernoff

hey screw it, lets just disable our firewalls too open up localhost

You sound like we force you to disable something. We don’t. If you don’t need Docker Desktop or another Electron based app having the same issue, no reason to turn it off.

If you have to use Docker Desktop and know another way around the issue - please share. For example, if you made an AppArmor profile that disables “restricted unprivileged user namespaces” only for Docker Desktop.

From my point of view: Staying on Ubuntu 23.10 and earlier is not considered a severe security threat. At least I never saw such claims anywhere. And that versions don’t have this security feature or don’t have it ON. So we are probably fine to temporarily disable something that was just rolled out a couple of months ago and we lived alright without. Especially if it’s needed to unblock work tools.

[joshchernoff]

@Spikhalskiy

more like this is giving the worst advice first. Why turn off everything globally when you could at least just turn it off via AppArmor at least reduce the risk vs just saying open the flood gates. We can do better than just saying turn it off globally. Most people here likely don't even know what they are doing when they just run the command seen in here. I'm hoping at the very least some noob with enough common sense sees my comment and thinks a little more critically.

also did you not see https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html ? If thats true for K8 then I would assume its true for a great number of other services possibly running open.

Also I'm gonna just leave this here for the rest of you https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md

[0xMALVEE]

✅ I was able to solve this issue with

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like an Electron and Chromium issue electron/electron#41066 and the above workaround was originally suggested in electron/electron#41066 (comment)

UPD: You can create a file /etc/sysctl.d/20-apparmor.conf or /etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent. It's a good idea to remove it when the fix to electron and Docker Desktop is released.

thanks for finding a temporary fix. <3

[Gu77ro77]

im giving up on Linux. it had potential, but in the end its just a ton of jumping through rediculously stupid hoops in order to achieve (if youre lucky) basic Functionality Logic= you dont need to design and build an entire electric propulsion system starting with mining the ore from sand, in order to drive a tesla linux=Error: Sub-process /usr/bin/dpkg returned an error code (1) try: sudo apt install sand_port7 or apt --auto-remove --happiness-life-timetotals because neckbeards

[arrrrny]

✅ I was able to solve this issue with

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It looks like an Electron and Chromium issue electron/electron#41066 and the above workaround was originally suggested in electron/electron#41066 (comment)

UPD: You can create a file /etc/sysctl.d/20-apparmor.conf or /etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent. It's a good idea to remove it when the fix to electron and Docker Desktop is released.

It worked, but on the restart it did not open again. sudo sysctl --system must be run immediately after kernel.apparmor_restrict_unprivileged_userns = 0 and creating the conf file ie /etc/sysctl.d/60-apparmor-namespace.conf

then rebooted and it worked

[Prashant20nov2003]

After upgrading it to 4.32.0 problem still exsists although using command that are given below it works fine $ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 $ systemctl --user restart docker-desktop its very annoying to do this whenever open machine everytime. Please make a permanant fix for this.

[vittorio88]

After upgrading it to 4.32.0 problem still exsists although using command that are given below it works fine $ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 $ systemctl --user restart docker-desktop its very annoying to do this whenever open machine everytime. Please make a permanant fix for this.

The following procedure persists across reboots:

You can create a file/etc/sysctl.d/60-apparmor-namespace.conf containing

kernel.apparmor_restrict_unprivileged_userns = 0

and it will make this setting permanent. It's a good idea to remove it when the fix to electron and Docker Desktop is released.

Reboot after editing the file, and docker-desktop should start-up.

[yuvii]

It's been 4 months. Are there any plans to resolve this issue?

[MrBns]

Though its works by disabling appArmor. But I don't think its a proper solution. After 4/5 month later this issue still exist. and thats not respectable @docker