'Permission denied' exception in multifilesystem/sync.py

[vonshednob]

I upgraded to Radicale 3.0.4 on ArchLinux inside an LXD container.
User and group of the process are radicale and all subdirectories in the data directory in /var/lib/radicale/collections have 0700 permissions, owned by radicale:radicale.
The webinterface works fine (can login and creating collections works).
However, when synchronising (Davx5, but that’s not relevant to the problem), I see Permission denied exceptions coming from multifilesystem/sync.py in the os.utime(token_path) call.

To test what’s going on I added another except PermissionError: pass and now it synchronises correctly.

I suspect that it could be my systemd radicale service file, but it seems sane:

[Unit]
Description=radicale - A simple CalDAV (calendar) and CardDAV (contact) server
After=syslog.target network.target
Requires=network.target

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ExecStart=/usr/bin/radicale
Group=radicale
IPAccounting=true
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=strict
ProtectHome=yes
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
ReadWritePaths=/var/lib/radicale
RemoveIPC=true
Restart=on-failure
RestrictAddressFamilies=~AF_PACKET AF_NETLINK AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@resources
UMask=0027
User=radicale

[Install]
WantedBy=multi-user.target

Any advice what else to test for?

[Unrud]

Any advice what else to test for?

Maye the utime syscall gets blocked by

SystemCallFilter=@system-service
SystemCallFilter=~@resources

[vonshednob]

I tried this, but without any success. No other update from my side so far.

[dotlambda]

The same happens to me on NixOS:

Apr 23 15:52:06 alonzo radicale[22208]: [2021-04-23 15:52:06 +0200] [22208/Thread-11] [ERROR] An exception occurred during PROPFIND request on '/redacted@redacted/redacted/': [Errno 13] Permission denied
Apr 23 15:52:06 alonzo radicale[22208]: Traceback (most recent call last):
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/app/__init__.py", line 127, in __call__
Apr 23 15:52:06 alonzo radicale[22208]:     status, headers, answers = self._handle_request(environ)
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/app/__init__.py", line 294, in _handle_request
Apr 23 15:52:06 alonzo radicale[22208]:     status, headers, answer = function(
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/app/propfind.py", line 372, in do_PROPFIND
Apr 23 15:52:06 alonzo radicale[22208]:     status, xml_answer = xml_propfind(
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/app/propfind.py", line 67, in xml_propfind
Apr 23 15:52:06 alonzo radicale[22208]:     multistatus.append(xml_propfind_response(
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/app/propfind.py", line 274, in xml_propfind_response
Apr 23 15:52:06 alonzo radicale[22208]:     element.text, _ = item.sync()
Apr 23 15:52:06 alonzo radicale[22208]:   File "/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/lib/python3.8/site-packages/radicale/storage/multifilesystem/sync.py", line 106, in sync
Apr 23 15:52:06 alonzo radicale[22208]:     os.utime(token_path)
Apr 23 15:52:06 alonzo radicale[22208]: PermissionError: [Errno 13] Permission denied

My service file is completely innocuous:

# /nix/store/18bdvhxxh56i79dsbi8bjjgnyg3m2q5c-unit-radicale.service/radicale.service
[Unit]
After=network.target
Description=A Simple Calendar and Contact Server

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/20dyxqvd9rnwzdnpdzb8vnv8w3vwa8wx-glibc-locales-2.31-74/lib/locale/locale-archive"
Environment="PATH=/nix/store/vr96j3cxj75xsczl8pzrgsv1k57hcxyp-coreutils-8.31/bin:/nix/store/ax8vv1ds6l81jx8cmflx3fvcl9jdxd2w-findutils-4.7.0/bin:/nix/store/rxkghln0km9axapv94iz3pcsln6ricms-gnugrep-3.4/bin:/nix/store/gdr4s4xx41n8krk9carr8amvncy8x3p3-gnused-4.8/bin:/nix/store/zpzn7c5g58srji21flwqmxzbnaa8w29j-systemd-246.6/bin:/nix/store/vr96j3cxj75xsczl8pzrgsv1k57hcxyp-coreutils-8.31/sbin:/nix/store/ax8vv1ds6l81jx8cmflx3fvcl9jdxd2w-findutils-4.7.0/sbin:/nix/store/rxkghln0km9axapv94iz3pcsln6ricms-gnugrep-3.4/sbin:/nix/store/gdr4s4xx41n8krk9carr8amvncy8x3p3-gnused-4.8/sbin:/nix/store/zpzn7c5g58srji21flwqmxzbnaa8w29j-systemd-246.6/sbin"
Environment="TZDIR=/nix/store/9jp4dspz5s53wx3803f99ck8lyfri1jf-tzdata-2020c/share/zoneinfo"



ExecStart=/nix/store/6m1fik6b4ka11sn32qs99ph9fmclrs53-radicale-3.0.5/bin/radicale -C /nix/store/sdgm1k5ngrmd7nq3ms2i6n7r2f1vi4jp-radicale.conf
Group=radicale
User=radicale

[SylRoo]

Just installed radicale 3.1.8 on ubuntu 24.04. I have exactly the same issue:

The webinterface works fine (can login and creating collections works).
However, when synchronising (Davx5, but that’s not relevant to the problem), I see Permission denied exceptions coming from multifilesystem/sync.py in the os.utime(token_path) call.

I managed to get around this with:
sudo sed -i 's/FileNotFoundError)/FileNotFoundError, PermissionError)/' /usr/lib/python3/dist-packages/radicale/storage/multifilesystem/sync.py

Two questions:

1. This workaround obviously skips the os.utime call altogether. What happens if the modification time is never updated on those files?
2. Did anybody figure out where that permission issue could come from? I could investigate a little more if I knew what this token file is and where it is located...

[SylRoo]

With a bit of debugging, I managed to find out where those token files are. It turned out that the files were owned by root. I have no idea how this happened. Problem was solved by deleting those token. A new synchronization re-created new tokens owned by the radicale user.
Sorry for the useless noise.