Uh-oh. Everything was going swimmingly, until I tried to test the desktop application sync!
I suspect this is because the symbolic link never resolves, and Nextcloud lists that folder as forever "Pending".
The folder is quite usable through-the-web, even with the pending "folder".
(I"m not 100% sure this is the problem, but the documentation is not clear, and a search for this exact error message turns up "External Storages are more trouble that they're worth" from some disgruntled user). #LunaticsProject # #Nextcloud
Yes. This seems to be the problem. Removing the target folder for the symlink causes the link (now broken) to disappear entirely from Nextcloud.
And THEN the desktop app syncs with the folder without complaint. :welp:
THAT would've been an acceptable failure mode for Nextcloud to have chosen for discovering a file or folder it can't read due to permissions or file ownership.
Hanging endlessly on it is NOT an acceptable behavior, and I'm really pretty shocked this was not dealt with whenever this External Storage thing was rolled out.
"I'm not mad. I'm just disappointed in you.
...
Very, very disappointed." :ani_baka:
I guess I should go file a bug report. AFTER I cool down. :welp:
Anyway, that's probably a show-stopper for the symlink method, unless that gets fixed. Thought I had an obvious save there, for a bit. 😥 #LunaticsProject # #Nextcloud
Okay, this is interesting. If I delete the symbolic link (owned by root) and replace it with the actual folder (still owned by root), the desktop application goes ahead and syncs, ignoring the folder in question (there's a warning/error message about it, but the rest of the folder is usable and is in fact synced on the filesystem).
🤔
I wonder what happens if I go back to the symlink, but let nextcloud own the symbolic link, while root owns the folder (and doesn't allow nextcloud to read it..?) #LunaticsProject # #Nextcloud
I tried changing the ownership of the symlink (a little tricky to do -- I didn't remember this, but you have to use a flag "-h" to get chmod to do that).
Anyway, it doesn't make much difference versus the link being owned by root. It's the ownership of the target folder that matters.
But also, I can't replicate the "HTTP transmission error" in my Nextcloud Desktop.
I get a much less serious error -- just "Error while loading the list of folders from the server", and specifically to the denied folder (so that's basically accurate).
The only really annoying thing now is in the web UI, where the "Size" column for this directory appears as "Pending", and so all of the containing folders do as well.
That's a little annoying, but I'm not sure if it's a show-stopper now.
I wish this was more clear cut.
Also, I'm not sure I can report this as a bug, though IMHO, it still is.
Anyway, the fact that I'm using the YunoHost package makes filling out the bug report kind of weird -- I can't get the results for the configuration report and other details. #LunaticsProject # #Nextcloud
Ich weiß wirklich nicht, was mit dem #Nextcloud Klienten nicht stimmt oder das ein Problem von #NixOS ist. Egal was ich mache, der Client will bei jedem Neustart warum auch immer die Konfiguration von .local zu .config migrieren was fehlschlägt und dadurch kann der Client nicht mehr synchronisieren und logt mich aus. Selbst wenn ich den Konfigurationsordner festlege funktioniert es nicht. Diese beiden Ordner zu löschen bringt auch nichts, das ganze geht einfach von vorne los.
Deswegen immer die Dokumentation lesen. Dass es so weit unten innerhalb des Wikis ist und dazu auch innerhalb des Wikis für den #Nextcloud Server, spricht aber auch nicht gerade für eine gute Organisation. Aber ich habe in den letzten 2 Tagen immer wieder gehört, dass die #NixOS Dokumentation ziemlicher Müll ist. Davon abgesehen ist NixOS aber ein geiles System.