Hello @ntnsndr Best to use the occ to uninstall the app and then try to install it again. If this does not resolve the issue you might have to report this in the nextcloud forum or the GitHub of the polls app directly.

Hey there, since package 5.8.1 the drag'n'drop bug is gone. Thx!

sorry for replying late: there's no cron job involved, maybe that's the issue? Everything needs to be done manually: nginx-config whenever Cloudron box is updated, in an SSH session running the script to start notify_push whenever NC app is restarted, using a terminal from Cloudron UI to access the docker container after running the start script, and using your ps-check command, I see a corresponding process. Additionally, running <occ notify_push:metrics> in a Cloudron terminal shows it works, all indicated stats are up-to-date and change over time.

There's many hits for "Could not acquire a shared lock on the config file" on the forum (most of them leading to nothing)

so you are referring to sieve rules support I guess if I read that issue correctly. Have you configured sieve in your nextcloud? Since the nextcloud mail app is acting like a webmail client, you have to configure that by hand I assume.

Marked as solved due to inactivity from the author.

The well-known is usually served up by the main domain (example.com) so for a start if your nextcloud is installed on a subdomain, the well-known needs to be configured outside this nextcloud instance. So make sure to have an app installed at example.com so it gets routed to Cloudron. Then you can configure this via https://docs.cloudron.io/domains#well-known-locations Though not exactly sure if this nextcloud app would expect the same things as mastodon, but you can try to set the well-known mastodon accordingly, maybe that works. Otherwise we may have to add support for whatever this needs.

Hello @firmansi Thanks for the report. Then I have to assume that it is some Nextcloud third party app issue with the latest update.

Thanks for your reply! I guess we'll just keep the existing users on oidc then. Or maybe, if they're willing to, they can migrate manually. Most shares and other tools (collectives, calendars) are shared via groups, not link.

@sponch thanks for the reminder

Here's how I've temporarily worked around the situation: Manually synced all auto upload folders to ensure I'm not missing any files Cleared the cache on the Nextcloud app Told it to ignore all pending uploads I think there is some sort of rate limit causing issues - once you get too many items pending re-upload, it just keeps hitting the server and Cloudron starts rejecting / ignoring requests from the client, which puts it into a weird state.

From cloudron side, you can get an app password with mail access for the user. This is easy with REST API. On nextcloud side, you have to figure how to automate a mailbox set up for a user with that password .

That did the trick! Thank you! We can close this topic now.

@jdaviescoates Pure gold! I just cleaned up 30ish GB I hope setting the max/min age to 30/7 should prevent this from building up anytime soon.

Thank you for your reply. I have disabled the Nextcloud standard login a while ago so for now users can only login via their Cloudron’s account (including me ). I will try to figure out how to revert that

Thank for the reply! I was able to resolve the issue. The external SSHFS volume was still registered in Cloudron, but the remote server was offline, causing the container to fail during startup. Since the mount point was stuck and not removable at first, I proceeded as follows: sudo rmdir /mnt/volumes/... mkdir /mnt/volumes/... cd /mnt/volumes/... By recreating an empty local folder at the exact path Cloudron expected, the app was finally able to start again. Once the app was running, I could remove the external volume cleanly from the Storage configuration in the Cloudron dashboard.