--verify-storage shows an error: 'VCALENDAR' must not have child collections -- how to fix?

[RalfJung]

When I run the verify-storage command, I get an error:

$ sudo /usr/bin/radicale --verify-storage
[2024-06-02 15:30:29 +0200] [930396] [ERROR] Invalid collection 'ralfj': 'VCALENDAR' must not have child collections

Unfortunately https://github.com/Kozea/Radicale/wiki/Server-Diagnostics---Troubleshooting does not give guidance for what to do in case of an error. I don't know how this situation came about (maybe a bug or an admin mistake when I set this up many years ago) -- how can I fix it?

[pbiering]

https://github.com/Kozea/Radicale/wiki/Server-Diagnostics---Troubleshooting extended, looks like you have an unsupported nested collection structure on the system.

[RalfJung]

Thanks for extending the docs!

Hm, no idea how that happened, I only ever created collections using radicale's UI I think.

Solution: check for any folder in which itself is a collection and move it on same level as $NAME. Check also content of related ".Radicale.props" file

I don't know what this means. /var/lib/radicale/collections/collection-root/ralfj looks as follows

total 224K
drwxr-xr-x 6 radicale radicale 4,0K Jun  2 15:30 .
drwxr-xr-x 5 radicale radicale 4,0K Jun  2 15:30 ..
drwxr-xr-x 3 radicale radicale 180K Jun  3 16:30 kalender.cal
drwxr-xr-x 3 radicale radicale  20K Jun  3 21:20 kontakte.vcf
drwxr-xr-x 3 root     root     4,0K Jun  2 15:30 .Radicale.cache
-rw-r--r-- 1 radicale radicale   54 Sep 22  2018 .Radicale.props
drwxr-xr-x 2 radicale radicale 4,0K Sep 22  2018 .well-known

The .Radicale.props in the root contains

{"ICAL:calendar-color": "#7908bf", "tag": "VCALENDAR"}

That seems a bit odd? The calendar should be the stuff in kalender.cal, right, not here in the root?

My Android client always showed two calendars and I always wondered why, as I only ever wanted to create one. I guess that is related. But I don't know what I have to do now -- can I just delete that .Radicale.props in the root?

[pbiering]

yes, delete .Radicale.cache (which was created by root anyhow, very strange) and .Radicale.props in this root folder.

[RalfJung]

That seems to fix the warning from --verify-storage. However, .Radicale.cache is being re-created whenever I run sudo /usr/bin/radicale --verify-storage. Probably that's why it is owned by root.

Also, on my phone, it still shows two calendars: ralfj and ralfj/kalender.cal. When I try to delete it from within the Android app (DAVx5), I get an HTTP error 500.

[RalfJung]

Actually when I try to delete it a second time then it works. But now things are very broken, I can't sync any of the other calendars / address books any more... and indeed I can see that kalender.cal has been completely deleted (even though in the app I told it to delete the other calendar, the one just called ralf). Good thing I made a backup before doing all this...

[RalfJung]

After restoring the backup, the strange ralfj calendar is still gone. Maybe the app didn't get the refreshed collection list or so. I pressed the sync button but maybe updating the collection list is different from syncing.

sudo -u radicale /usr/bin/radicale --verify-storage shows no warnings now and everything looks good in the app. So I think this is all resolved now.

[pbiering]

That seems to fix the warning from --verify-storage. However, .Radicale.cache is being re-created whenever I run sudo /usr/bin/radicale --verify-storage. Probably that's why it is owned by root.

You should not run any radicale command as different user than the service user itself. Otherwise it can happen that files/directories cannot be adjusted because of permission problems.

why .Radicale.cache is created during --verify-storage in unexpected directories is also strange to me and makes not much sense...needs to be investigated, will be tracked in #1509

[RalfJung]

You should not run any radicale command as different user than the service user itself. Otherwise it can happen that files/directories cannot be adjusted because of permission problems.

That makes sense, but may be good to call out in the docs. Currently I first try to just run the command which leads to permission errors, so then using sudo is the obvious choice -- and the operation sounds read-only so I wasn't worried about somehow messing up permissions.

Thanks for your help!

[pbiering]

Doc updated: https://github.com/Kozea/Radicale/wiki/Server-Diagnostics---Troubleshooting