rama3124

Is there a way to manually force the other one to update via CMD? I'm not that familiar with docker compose commands since I usually just rely on unraid app store

Yes they are run with the same docker compose file: services: monica: image: monica container_name: monica env_file: .env ports: - 880:80 volumes: # CHANGE YOUR PATH HERE - /mnt/user/appdata/monica:/var/www/html/storage labels: - traefik.enable=true - traefik.http.routers.monica.entryPoints=https - traefik.http.routers.monica.middlewares=securityHeaders@file - traefik.http.routers.monica.rule=Host(`monica.mydomain.com`) restart: always networks: - custom cron: image: monica container_name: monica-cron env_file: .env restart: always volumes: # CHANGE YOUR PATH HERE - /mnt/user/appdata/monica:/var/www/html/storage command: cron.sh networks: - custom networks: custom: driver: bridge name: custom external: true

Could this somehow be related to the fact I'm running two versions of the same container (one for cron)? When i check the docker digests, I see that one of the SHA256 terms matches the latest version while one doesn't monica latest sha256:23174c71b2d245588572859d470629ad282db565d78692310042b9261cb97ac4 583089e9e94f 6 days ago 691MB monica latest sha256:7d55a04bce4e56da3fa047d23bd2e616cba6327bdca8147ed7255f4dc03e6cdf 583089e9e94f 6 days ago 691MB

I'm already on 7.3 RC 1 and it seems to still happen. I wonder if it is an issue specific to monica, how can i check if it is already the latest version or not?

Hi, I run a single stack using this plugin with two versions of the monica container, and the stack seems to permanently show 'update available' even after I click the option to update (it says I need to update 7d55a04b to 23174c71). Is there a way I can manually force it to update using command line or check that it isn't already on the latest version? Thanks

Does this plugin update automatically to the newest version even when it is manually installed? Or do i need to keep installing it again to keep it up to date?

Worked perfectly! Thanks for your help and your work on this great container

And do i need to do anything with the containers that use postgresql as a dependency (in my case authentik)? Like do i need to stop authentik before doing this dump? Or recreate the database in authentik?

Thanks, this was really helpful and thorough. Just one other question, if I have multiple databases in the same postgresql container, I'm assuming I can just repeat this process for each one?

Hi, What is the process to upgrade to the postgresql 18 container from an earlier version? I have version 15, can I just dump all the databases and then import them back into the new one and rename the same appdata folder?

Yeh this didn't fix my problem, it's still happening at the same time every week

Actually think I found the problem. I also run duplicacy, which backs up my backup share on Sundays at 2am but we just switched over to daylight savings time a few weeks ago in Australia. My suspicion is that duplicacu is actually trying to run the backup at 1am since they haven't corrected for daylight savings time, which is the same time as my appdata backup. I've changed the schedule so let's see if it happens next week

My mover runs at 3.40am every morning and the appdata backup happens at 1am Sunday. The app data backup seems to trigger the problem each week when it runs (it errors out since it cant create folders) but I don't understand why since the mover runs 2 hours later

Just happened again for me this morning too. It seems to happen the exact same time every Sunday morning unraid-diagnostics-20251019-0700.zip

Is this template going to be updated to the new version (2.0)?

Only my cache drive is zfs but my main array is xfs, the shares affected should be moving to the main array as secondary storage No prbs, I hadn't upgraded my zfs pools after upgrading from unraid 6.x to 7.x but now I've done that too, hoping that will somehow help but will post diagnostics next week if it happens again

This is my output for zfs list cache 56.4G 806G 181K /mnt/cache cache/appdata 8.91G 806G 8.91G /mnt/cache/appdata cache/user2 128K 806G 128K /mnt/cache/user2 cache/backups 6.51G 806G 6.51G /mnt/cache/backups cache/data 826K 806G 826K /mnt/cache/data cache/domains 20.7G 806G 20.7G /mnt/cache/domains cache/isos 128K 806G 128K /mnt/cache/isos cache/nextcloud 128K 806G 128K /mnt/cache/nextcloud cache/rama 128K 806G 128K /mnt/cache/rama cache/system 20.1G 806G 20.1G /mnt/cache/system

It definitely seems related to the error you mentioned above since I got the same error this morning when I tried to create files and folders in the two shares: Oct 12 06:50:47 Unraid shfs: /usr/sbin/zfs create 'cache/rama' 2>&1 Oct 12 06:50:47 Unraid shfs: cannot create 'cache/rama': dataset already exists Oct 12 06:50:57 Unraid shfs: /usr/sbin/zfs create 'cache/backups' 2>&1 Oct 12 06:50:57 Unraid shfs: cannot create 'cache/backups': dataset already exists

I guess new diagnostics now wouldn't help since the problem is temporarily resolved but the old one i posted above was done while the problem was happening. The shares were rama and backup, and I couldn't create any files/folders in either but could create them normally in the other shares The other strange thing is that both times it happened on Sunday morning. If it happens again next Sunday morning, it would seem it's somehow related to a process that occurs weekly

It's happening again :( Can't create files or folders in several of my shares (same ones as last time) If it try 'touch test' or 'mkdir test', it says invalid argument. Stopping and starting the array seems to temporarily fix the problem, any tips on how to troubleshoot this?

Stopping and starting my array sorted the issue. It was really strange though, I couldn't create files or folders in 3 of my shares. All attempts to create files using touch or folders using mkdir prompted an invalid argument error. Could this mean corruption in my drives?

Yeh you're right, not sure what was going on but a reboot fixed it. Thanks for your work on this amazing plugin!

Hi I woke up this morning to an error with my appdata backup plugin saying that it couldn't create a destination folder. I tried creating files and folders manually in the backups share using terminal but received an 'invalid argument' error. The same applies to a couple of my other shares but no all of them I've tried scrubbing my cache and running some short SMART self tests on my drives but haven't noticed any issues Any advice on how to troubleshoot this would be appreciated, the diagnostics are attached below unraid-diagnostics-20251005-0930.zip

I tried to create to run the following in terminal: mkdir /mnt/user/backups/appdatabackups/ab_20251005_075421 but it said invalid argument. Actually it says invalid argument even if I just say mkdir test ab.debug.log

Suddenly just started getting the following error when running this plugin after years without issues: Cannot create destination folder Anyone know why this started happening and how to fix it? TIA