permission denied on .Radicale.lock

[nin9s]

after starting the container everything is running fine for a few days and than radicale always complains about permission denied every time I try to access a calendar.

2019-09-30 08:29:55,967 - [7fc404417b10] ERROR: An exception occurred during PROPFIND request on '/nines/': [Errno 13] Permission denied: '/data/collections/.Radicale.lock'
2019-09-30 08:30:12,673 - [7fc404417b10] ERROR: An exception occurred during PROPFIND request on '/': [Errno 13] Permission denied: '/data/collections/.Radicale.lock'

any help is appreciated.

[tomsquest]

No idea about that file .Radicale.lock.

Do you have any container restarting policy?

I don't know if the logs of the Docker daemon contain something related.

[nin9s]

regarding https://radicale.org/storage/ When the data is accessed by hand or by an externally invoked script, the storage must be locked. The storage can be locked for exclusive or shared access. It prevents Radicale from reading or writing the file system. The storage is locked with exclusive access while the hook runs.

dont you have this file in your data folder?

restart policy is set to always but the container wasnt restarted for days. The problem only comes up after a few days of running. Its gone after restart.

what exact docker daemon log do you mean?

[tomsquest]

Yes, I do have this file. But no, I don't have any errors (running with no problem for 16 days currently)

what exact docker daemon log do you mean?

I was meaning that an external source could kill the radicale container, thus leaving the lock file then Radicale would consider itself locked.

For another hypothesis, what are the permission of the lock file?

Mine:

$ stat collections/.Radicale.lock 
  File: collections/.Radicale.lock
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd01h/64769d    Inode: 4197905     Links: 1
Access: (0660/-rw-rw----)  Uid: ( 2999/radicale)   Gid: ( 2999/radicale)
Access: 2019-09-14 07:02:19.447453732 +0200
Modify: 2019-09-14 07:06:28.814686318 +0200
Change: 2019-09-14 07:06:28.814686318 +0200
 Birth: -

[nin9s]

I was meaning that an external source could kill the radicale container, thus leaving the lock file then Radicale would consider itself locked.

no, the container was running for a couple of days without restart

/ # cd data/
/data # stat collections/.Radicale.lock
  File: collections/.Radicale.lock
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fe00h/65024d    Inode: 2630131     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 2999/radicale)   Gid: ( 2999/radicale)
Access: 2019-09-30 12:16:04.000000000
Modify: 2019-09-30 12:16:04.000000000
Change: 2019-09-30 12:16:04.000000000

[nin9s]

I will report back if the permissions maybe change as soon as it stops working (restarted the container recently)

wil report back

[tomsquest]

Ok.

Closing in between. Re-open if needed.

[nin9s]

happened again. seems like the permissions changed, somehow to "my" user

/ # stat collections/.Radicale.lock
stat: can't stat 'collections/.Radicale.lock': No such file or directory
/ # stat /data/collections/.Radicale.lock
  File: /data/collections/.Radicale.lock
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fe00h/65024d    Inode: 2630131     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1000/ UNKNOWN)
Access: 2019-09-30 12:16:04.000000000
Modify: 2019-09-30 12:16:04.000000000
Change: 2019-09-30 22:13:09.000000000

any ideas?

[tomsquest]

Hum, could it be that the data volume is mounted on NFS or something (samba...) that could play with the permissions?

[nin9s]

No that’s not the case but was it is is that the folder is located inside the users home folder with ID 1000. I’ve never encountered any issues before and all my containers are having it’s data folder in /home/uid1000user/container_name/data

[nin9s]

seems like its fixed with the following configuration - I guess its because of the UID/GUID. Didnt use it before explicitely.

docker run --name radicale --runtime runc -v /home/strn/docker/radicale/data:/data -v /home/strn/docker/radicale/config:/config:ro -p 5232:5232/tcp --net docker_unimatrix01 --restart no -h 1d4116316bc5 --expose 5232/tcp -e 'UID=2999' -e 'GUID=2999' -e 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -d --entrypoint "docker-entrypoint.sh" tomsquest/docker-radicale:latest radicale --config /config/config

instead of:

docker run \
-d \
--name radicale \
-p 5232:5232 \
--network=docker_default \
--cap-drop ALL \
--security-opt="no-new-privileges:true" \
--cap-add CHOWN \
--cap-add SETUID \
--cap-add SETGID \
--cap-add KILL \
--pids-limit 50 \
--health-cmd="curl --fail http://localhost:5232 || exit 1" \
--health-interval=30s \
--health-retries=3 \
-v /home/strn/docker/radicale/data:/data \
-v /home/strn/docker/radicale/config:/config:ro \
  tomsquest/docker-radicale:latest

[tomsquest]

If this is the case, I am lost.

UID and GID (not GUID) are use to override the identifier of the user and group named radicale which "owns" the /data dir.

From entrypoint.sh:

if [ -n "$GID" ]; then
    groupmod -o -g "$GID" radicale
fi

if [ -n "$UID" ]; then
    usermod -o -u "$UID" radicale
fi

[nin9s]

Excuse me, you are right Am using the following and it seems to work

--cap-add SETUID \ --cap-add SETGID \

Does that make sense?

[tomsquest]

Yes, those capabilities are certainly required when UID or GID are set. Else there would have been permission denied errors at container start.