I have installed the OS, but i cannot install anything from the app store. when i try, the installation stays at 5% and i get the following error:
“Failed to pull image after trying 4 different mirror methods. If this is a private image, verify registry credentials and pull permissions”
Is there any fix for this?
Yeah this one’s pretty common, and it’s usually not the app itself, it’s the system struggling to pull Docker images.
That error basically means ZimaOS tried multiple mirrors and couldn’t download the image at all.
A few things to check (keep it simple):
docker pull hello-world
If that fails > it’s definitely network / DNS / firewall, not the App Store
Also worth noting, ZimaOS App Store is just Docker under the hood, so if Docker can’t pull, nothing in the App Store will install.
If that docker pull hello-world works fine, then we look deeper. If it fails, you’ve already found the root cause.
I’ve NEVER had any success pulling apps from the App Store. I have always had to do a custom install for some reason. And even then sometimes I still run into issues. I’m struggling right now because I can’t get Spoolman installed via the app store or those a custom install. I figured maybe it was time to download portainer since I’m not good at this and I can’t get that to install either. To be clear, they download just fine but when I go to their port they never actually start up. Any ideas?
That actually sounds different to the original issue.
If the images are downloading fine but nothing loads on the port, then the problem isn’t the App Store, it’s that the containers aren’t starting properly or aren’t binding to the port.
First thing I’d check is whether the containers are even running:
docker ps -a
Look at the STATUS column
Then check logs for one of the apps that won’t start:
docker logs <container_name>
That will usually tell you exactly why it’s failing.
Couple of common causes on ZimaOS:
Also worth checking what ports are actually exposed:
docker ps
Make sure you see something like 0.0.0.0:PORT-> inside the PORTS column.
Right now I wouldn’t reinstall anything yet, you’ll just hit the same issue again. The logs will point straight to the cause.
checking docker ps
x@ZimaOS:~ ➜ $ docker ps -a
WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get “http://%2Fvar%2Frun%2Fdocker.sock/v1.47/containers/json?all=1”: dial unix /var/run/docker.sock: connect: permission denied
whats wrong with mine ??
fresh install zimaOS v1.6.1
That looks more like a permissions/session issue rather than Docker itself being broken.
On ZimaOS, the normal user sometimes does not have permission to access the Docker socket after a fresh install or after user changes.
I would first check whether Docker itself is actually running correctly by using sudo:
sudo docker ps -a
If that works, then the issue is just user permissions to /var/run/docker.sock.
Also interesting is this part:
WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied
That suggests the current user also cannot read the Docker config directory under /DATA/.docker.
Can you also post:
whoamigroupsls -l /var/run/docker.sockls -ld /DATA/.docker
That should tell us pretty quickly whether the user was added correctly to the docker group or if permissions got messed up during setup.
I think he meant whoami;groups;ls -l /var/run/docker.sock;ls -ld /DATA/.docker (the newlines or ‘;’s got stripped for some reason).
Ah yes, Discourse probably stripped the formatting together.
You can run them either one at a time or all together like this:
whoamigroupsls -l /var/run/docker.sockls -ld /DATA/.docker
or:
whoami; groups; ls -l /var/run/docker.sock; ls -ld /DATA/.docker
That should show whether the user has Docker socket access and whether the .docker folder permissions are wrong.
x@ZimaOS:~ ➜ $ whoami;groups;ls -l /var/run/docker.sock;ls -ld /DATA/.docker
x
wheel samba
srw-rw---- 1 root docker 0 May 19 09:43 /var/run/docker.sock
drwx–x— 12 root root 4096 May 19 09:44 /DATA/.docker
I am new, so hope I am not speaking out of turn…. would this help?
sudo usermod -aG docker $USER
(you will have to log out then back in to see it if you type ‘groups’ at the CLI)
Or, is this already set by default?
after login & logout
x@ZimaOS:~ ➜ $ whoami;groups;ls -l /var/run/docker.sock;ls -ld /DATA/.docker
x
wheel docker samba
srw-rw---- 1 root docker 0 May 19 09:43 /var/run/docker.sock
drwx–x— 12 root root 4096 May 19 09:44 /DATA/.docker
That should at least solve some permissions problems since your user is now in the docker group. Notice that /var/run/docker.sock has docker group read/write permissions, and you now are part of the group, so access to it should be allowed. Now, will that solves all the problems, I am not certain.
restart my mini-pc
and try app from app-store… still error..
i try this
x@ZimaOS:~ ➜ $ docker ps -a
WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
It looks as we still have a permissions problem on the DATA directory as it is owned by root and allowed write/execute access only by root and the root group can only execute.
I am not knowledgeable enough to know if changing the ownership of DATA to $USER:$USER recursively would cause even greater problems down the line. I am still waiting on my Zimaboard 2 to arrive and get to know it better. It would be better if docker would bind that DATA directory path to a directory outside the container to the userspace instead of rootspace in the container. All sorts of issues may happen when you do that. I will have to give way to someone who knows Docker more than I do and the way ZimaOS deploys Docker apps.
I think your thinking is actually reasonable here because it definitely does look permission-related somewhere in the stack.
I’d just be very careful changing ownership of /DATA recursively on ZimaOS though, because a lot of the system, Docker storage and app management expects root ownership there by design.
From what I’ve seen, when containers download correctly but the apps themselves fail to load, it’s usually more specific than the whole /DATA directory ownership itself. Things like:
can all cause very similar symptoms.
Your point about bind mounts and container/user mapping is definitely valid though. I think checking the actual ownership/permissions of the specific app folders under /DATA/AppData/ is probably safer than changing /DATA globally.
Interested to see what you find once your ZimaBoard 2 arrives because these kinds of Docker/storage edge cases are becoming more common on newer ZimaOS builds.