Named volumes are created with different owner ID (100, 1000, 0)?

Product support balenaEngine
1

It is unclear to me how the owner ID of a named volume is set when deploying a new balena application or when purging data.

So I have named volumes where the owner ID is 100, 1000 and 0 (= root).

After purging data I see that the owner ID of the named volume has been changed from 1000 to 100 or 0.
This is a problem as the user (ID = 1000) of my container service can no longer write to the named volume as it has a different owner ID.

An example where the owner ID = 0 (= root)

oot@4d176de:/var/lib/docker/volumes/1284969_node-red-data2# ls -l
total 4
drwxr-xr-x 2 root root 4096 Nov  7 07:24 _data

An example where the owner ID = 100

root@4d176de:/var/lib/docker/volumes/1284969_node-red-data# ls -l 
total 4
drwxr-xr-x 2 100 root 4096 Nov  7 07:24 _data

An example (of another application on another device) where the owner ID = 1000

root@ba7c427:/var/lib/docker/volumes/1481607_node_red_data# ls -l  
total 4
drwxr-xr-x 5 1000 1000 4096 Nov  7 07:14 _data
2

I have also seen following related post Permission denied for persistence storage

This post suggests to change the owner of the respective folder at runtime in the start script, but I am using docker image nodered/node-red:1.0.2-12-arm32v7 and in that case it is not clear to me how I can do this ?

3

Hi there!
Can you share a Dockerfile and docker-compose file samples, reproducing the described behavior?
Also, did you try something like this: Permission denied for persistence storage

5

Hi,

I haven’t tried Permission denied for persistence storage (in fact I don’t know how I can do that for my docker service).

My (node-red) Dockerfile and docker-compose file can be found in my github repository:

kr
Jan

6

Sweet! I see there is an alpine node-red base image too :slight_smile: https://github.com/node-red/node-red-docker/blob/master/.docker/Dockerfile.alpine
You should be able to use that, and just use the steps defined here Permission denied for persistence storage . Cheers!

8

I guess I can also add an ENTRYPOINT in my node-red docker file that is running a script that is setting the owner of the /data folder and then starts node-red (with command npm start -- --userDir /data)

9

Yeah, an entrypoint script might be a good way to go. Just note that some of the functionality offered from the balenalib/ base images will be lost if you overwrite the entrypoint. Most notably the UDEV=1 feature that helps keep /dev in the container fresh as devices get plugged in or out. But depending on your usecase that might not be an issue at all.

11

Thanks for the remark concerning UDEV. The service was not based on a balena lib/ base image so from that perspective my entrypoint solution doesn’t change anything.

FYI the details of the solution:
1/ I have fixed it by adding the following lines to my node-red Dockerfile:

COPY ./entrypoint.sh .

# the below entrypoint replaces the entrypoint of the nodered/node-red
ENTRYPOINT  ["bash", "entrypoint.sh"]

2/ and the contents of the entrypoint.sh =

#!/bin/bash

echo "Allowing node-red to write to folder /data ..."
sudo chown node-red:node-red /data

echo "Starting node-red ..."
npm start -- --userDir /data
14

Thanks for sharing your solution @janvda.

16

Although this solution works, it means that I should enable sudo in my container which actually defeats the point of running my container as a non root user.

So it would be better to have a solution that doesn’t require to enable sudo in order to change the UID of the named data volume.