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.

@james said: Hello @apesorguk That is a good idea. Nextcloud apps are a notorious offender in breaking Nextcloud setups. Totally agree, we have said to nextcloud that they should not release updates and apps until tested with all other apps. They need to get rid of untested apps as well.

@andreasb said: it looks like notify_push is up and running I honestly don’t understand how you managed to get this working. I spent about 5 hours today trying to set it up and still didn’t get the result I expected. @reboot cron job simply doesn’t work. It’s mentioned in the docs but I’ve never seen it run in the logs. @service does run but only once. Аfter subsequent Nextcloud restarts the job never triggers again. My version of the script works fine if I run it manually from the terminal like this /app/data/notify_push.sh. The service starts and all checks pass. root@71780ea5-011c-4c09-886e-5f7e17e0b670:/app/code# /app/data/notify_push.sh ; sleep 1 ; ps aux | grep notify_push ; ss -tlnp | grep 7867 ✓ redis is configured ✓ push server is receiving redis messages ✓ push server can load mount info from database ✓ push server can connect to the Nextcloud server ✓ push server is a trusted proxy ✓ push server is running the same version as the app configuration saved => notify_push started on port 7867 root 265 0.3 0.0 25676 8796 ? Ssl 15:57 0:00 /app/code/apps/notify_push/bin/x86_64/notify_push --allow-self-signed --nextcloud-url http://172.18.20.152 --port 7867 /app/code/config/config.php root 286 0.0 0.0 4104 2100 pts/1 S+ 15:57 0:00 grep --color=auto notify_push LISTEN 0 128 0.0.0.0:7867 0.0.0.0:* users:(("notify_push",pid=265,fd=10)) If I set up a cron job to run every 5 minutes. */5 * * * * echo "=> Enabling notify_push" && /app/data/notify_push.sh I can see in the logs that everything looks fine: Apr 16 18:30:41 ✓ redis is configured Apr 16 18:30:41 ✓ push server is receiving redis messages Apr 16 18:30:41 ✓ push server can load mount info from database Apr 16 18:30:41 ✓ push server can connect to the Nextcloud server Apr 16 18:30:41 ✓ push server is a trusted proxy Apr 16 18:30:41 ✓ push server is running the same version as the app Apr 16 18:30:41 configuration saved Apr 16 18:30:41 => notify_push started on port 7867 But in reality the process doesn’t survive after the script finishes. If I check manually with ps aux | grep notify_push ; ss -tlnp | grep 7867 there’s nothing in the terminal. Claude suggested this might be a cgroup-related issue in containers. The process started from cron gets attached to its cgroup and when the cron job exits, the process is killed along with it. I’m not sure how accurate that is. Maybe most people who claimed to have notify_push working probably didn’t verify it properly, since the warning disappears from the Nextcloud admin panel. It looks like it’s working, even when it actually isn’t.

Hi @james Thank you for your feedback. I searched a bit and i found this bug report here in GitHub, it's exactly my problem. Seems to be a bug. When i pres F12 in Firefox, i can see it. First, thought about if i have a wrong configuration, but i guess that Cloudron supports the optimal configuration for Nextcloud, so there's no need to to anything, just wait for the bugfix. https://github.com/nextcloud/server/issues/59468 Has anyone else the same issue? Thanks, Eixen

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.