If it helps, we run verdaccio inside Kubernetes and the /verdaccio/storage path is mounted on an AWS EBS volume.

Do you think this should be enough to fix it?

RUN  chown -R verdaccio:verdaccio /verdaccio/storage && \
     chown -R verdaccio:verdaccio /verdaccio/conf/

Looks like this is already in the Dockerfile

RUN addgroup -S verdaccio && adduser -S -g verdaccio verdaccio && \
    chown -R verdaccio:verdaccio "$APPDIR" && \
    chown -R verdaccio:verdaccio /verdaccio

I think the problem might be that we specify the volume after that command and after assuming the verdaccio user.

VOLUME ["/verdaccio"]

That's not the problem unfortunatelly. It won't help. Until the problem will be found, the following unsecure workaround can be used, add this to your deployment right before the verdaccio container spec:

{
    "initContainers": [
        {
            "name": "verdaccio-init",
            "image": "busybox",
            "imagePullPolicy": "IfNotPresent",
            "command": [
                "sh",
                "-c",
                "chmod 777 -R  /verdaccio/storage"
            ],
            "volumeMounts": [
                {
                    "name": "verdaccio-storage",
                    "mountPath": "/verdaccio/storage"
                }
            ]
        }
    ]
}

Can that can be tested in a local environment?

I think you could use minikube to test it locally. Kubernetes mounts the volume just before the dockerfile's CMD command as root. Thats why we cannot write to the storage folder.

Cool, thanks for that 👍

This is not a kubernetes specific problem unfortunately. If you run the following command the image is going to fail with EPERM, because docker is mounting the volumes as the host user or root.
docker run -it -v ~/test:/verdaccio/storage verdaccio/verdaccio:latest

The issue is tracked here.

@adrianchifor So to recap this, the fix for this problem is to set this on the PodSpec:

"securityContext": {
    "fsGroup": 101
}                        

Where 101 is the verdaccio group id. Kubernetes is going to give permission for that group to write on the attached volume

Shipped under v2.2.5. Docker image will be ready soon.

@markpeterfejes @juanpicado cheers guys!

I wonder if this fix on npm 5.1.0 is related with this
Releases notes:

npm/npm@58be2ec Make sure uid and gid are getting correctly set even when they're 0. This should fix some Docker-related issues with bad permissions/broken ownership. (@rgrove)
(@zkat)

npm/npm@24ec9f2

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.