Joly0

Ähh, no. For example i cloned the perplexica github repo to my array, not the compose manager project directory. I created a new stack on the compose page and pointed the stack directory to the cloned repo directory. Still the compose file that perplexica ships with is not showing up in the compose manager page, because the plugin expects the file with a the name "docker-compose.yml", perplexica uses "docker-compose.yaml". My patch fixes this.

Hey @primeval_god could you take a look into my pr https://github.com/dcflachs/compose_plugin/pull/33 and maybe merge it? Would be great to have this implemented. Currently i have to apply my changes manually after reboots on one of my servers

Thanks, worked, but tbh not a really "elegant" solution 😅

Hey, i have a server that i registered with unraid connect before i changed its name. Now the name is not updated in the unraid connect dashboard

There is actually. Some dockers (for example nextcloud-aio) and various dockers i created using docker compose plugin use volumes and not mounts (mounted to /mnt/cache/appdata for example) and therefore to be safe, i keep it for the time being

Hey guys, i did a similar question a long while back ( i think just a few days after this plugin came out) on how to use the dataset exclusion patterns for the docker share when it is under /mnt/cache/docker and sitting on a zfs formatted pool. I now had to switch from the zfs backend driver to overlay2 due to various issues and renamed the old share from "docker" to "docker-old" and created a new share called "docker". When i run "zfs list" i get this: cache/docker-old/wolhvhslvf29k8t3pivzaxgeo 304K 318G 1.05G legacy cache/docker-old/wveaw68gkv2pva12ry251lvvw 288K 319G 1.30G legacy cache/docker-old/x4szq66lf0kxs1hjvyli9vvcp 160K 319G 1.05G legacy cache/docker-old/x9rtcl22u2gv15xsca2kn73vc 328K 318G 679M legacy cache/docker-old/xuwh6qbuz8q154w33lqsskxtw 1.86G 318G 2.99G legacy cache/docker-old/y5n8i1wbdw946rl40gdp7hhlg 572M 318G 1019M legacy cache/docker-old/y6crl33ldujwb9jfcyeb97hly 19.0M 318G 626M legacy cache/docker-old/y9nro0dg7tbovdah2z0k38x4r 304K 318G 1.05G legacy cache/docker-old/ygpppknipp372joltaaefqpql 541M 318G 1.14G legacy cache/docker-old/yiretnbh62p6135tcgtjtnj8a 100K 318G 100K legacy cache/docker-old/yko1q8i6q99g2asu9ogy0b2rl 304K 319G 1.33G legacy cache/docker-old/ykuwgidf4wn57ynrtgbbqyefj 541M 318G 1.14G legacy cache/docker-old/ynvwhtzlynd8w4kca5iun3k5m 160K 318G 1.05G legacy cache/docker-old/ypqwyhi8ch1gmi8qqdomph5g1 448K 318G 2.95G legacy cache/docker-old/yvbxcyaq33rtsfg38w9l1wyv6 288K 318G 626M legacy cache/docker-old/zal6250uewuv703rtmyirivb2 384K 318G 463M legacy cache/docker-old/ztajorcy58sr9k0k8sdhhcsto 19.0M 318G 626M legacy cache/docker-old/zumi4wozbdoy2czeysshijf5t 160K 318G 1.33G legacy cache/domains 9.80G 318G 9.80G /mnt/cache/domains cache/system 968K 323G 968K /mnt/cache/system etc The problem is, that after renaming the share, the zfs master plugin wont hide it anymore. I had the exclusion pattern previously set to "/docker/.*" (without the ") and now i changed it to "/docker-old/.*" (also without the "), but for some reason, the datasets are not hidden anymore and the main page takes ages to load. What could be wrong? It worked previously I could probably delete the old share, but as i might have forgotten to move something, i want to make sure and keep it for a while, until i am 100% certain i didnt miss anything

Hey, unfortunately i wasnt able to solve this problem

Skipping virtualenv creation, as specified in config file. [Main][2025-01-07 16:29:50,264][INFO] = LOG LEVEL: INFO Traceback (most recent call last): File "/code/main.py", line 24, in <module> db = Database(logger) File "/code/DapsEX/database_cache.py", line 13, in __init__ self.initialize_db() File "/code/DapsEX/database_cache.py", line 23, in initialize_db with self.get_db_connection() as conn: File "/code/DapsEX/database_cache.py", line 17, in get_db_connection conn = sqlite3.connect(Settings.DB_PATH.value) sqlite3.OperationalError: unable to open database file Running main.py as 1000:1000 Did not help either unfortunately

Hey @grtgbln I tried to install daps-ui and only get this in the logs: Skipping virtualenv creation, as specified in config file. [Main][2025-01-07 10:20:52,510][INFO] = LOG LEVEL: INFO Traceback (most recent call last): File "/code/main.py", line 24, in <module> db = Database(logger) File "/code/DapsEX/database_cache.py", line 13, in __init__ self.initialize_db() File "/code/DapsEX/database_cache.py", line 23, in initialize_db with self.get_db_connection() as conn: File "/code/DapsEX/database_cache.py", line 17, in get_db_connection conn = sqlite3.connect(Settings.DB_PATH.value) sqlite3.OperationalError: unable to open database file Updating group appgroup GID to 100 Updating user appuser UID to 99 Running main.py as 99:100 I do not have kometa and posters, so i removed the requirement for those paths and changed the uid and gid, but is that the reason it fails to start?

Hey, i think mover tuning plugin breaks the new feature "empty disk" When i run mover start -e disk2 |& logger & i get this output in syslog: Dec 12 00:14:16 Tower root: mover: started Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs unmount 'cache/backup' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs destroy 'cache/backup' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs mount 'cache/backup' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs unmount 'cache/filerun' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs destroy 'cache/filerun' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs mount 'cache/filerun' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs unmount 'cache/nextcloud' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs destroy 'cache/nextcloud' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs mount 'cache/nextcloud' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs unmount 'cache/safe' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs destroy 'cache/safe' 2>&1 Dec 12 00:14:16 Tower shfs: /usr/sbin/zfs mount 'cache/safe' 2>&1 Dec 12 00:14:16 Tower root: mover: finished Though when i run mover.old start -e disk2 |& logger & it works and empties the disk: Dec 12 00:19:31 Tower root: mover: started Dec 12 00:19:33 Tower root: move: /mnt/disk2/.... Success Dec 12 00:20:09 Tower root: move: /mnt/disk2/.... Success Dec 12 00:20:10 Tower root: move: /mnt/disk2/.... Success Dec 12 00:20:54 Tower root: move: /mnt/disk2/.... Success Dec 12 00:21:30 Tower root: move: /mnt/disk2/.... Success Dec 12 00:21:30 Tower root: move: /mnt/disk2/.... Success

Hey @ich777 @datarepos i have the same ugreen NAS but havent noticed this issue, though i have my ugreen now in a separate room that i rarely look into and i have just restarted my ugreen, therefore cant replicate this issue now. I will try to leave it powered on for a few days and will report back, if i notice the same issue

Hey guys, maybe some can help me. So i have purchased a green cell 2000va ups on german amazon. I installed the nut plugin and let it detect the driver. It suggested the "nutdrv_qx" driver, so i tried that first, but i noticed in the dashboard, that "Battery Charge" and "Runtime Left" were missing. So i switched to the second recommendation "blazer_usb". Now "Batter Charge" is shown aswell, but the "Runtime Left" is still missing. The detect function suggests a third driver "nutdrv_atcl_usb" but that is not to be seen anywhere on the selection. Should i try that driver and if so, how can i do so? Or is there another reason, why the runtime left is not showing up?

Btw, this has been resolved. The amp template should be visible again in the CA

I have requested to remove the dupliacte flag here you could react to it maybe to raise importance for this (maybe even ping squid)

Hey, the APP "AMP" in the Repository by "CorneliusJD" is no longer visible. I can see, that this repo is marked as a duplicate here https://github.com/Squidly271/Community-Applications-Moderators/blob/1e509047f02e05fbabbb5a357a766d84e50d56a8/Repositories.json#L611 I think this is an error, because the image thats in the CA and the now hidden repo use different images and different settings. They work quiet differently and also the now visible AMP image had a bug in its release and wasnt updated for over a year til recently. So i personally would prefer the AMP image from the CorneliusJD repo Also the Image by MitchTalmadge is the more "Official" one, compared to the one by ImageGenius

It looks like the repo has marked as duplicate and therefore is hidden https://github.com/Squidly271/Community-Applications-Moderators/blob/1e509047f02e05fbabbb5a357a766d84e50d56a8/Repositories.json#L611 I think this is a mistake

Any issue with the recently added tab in CA? I see every app is new, except all the language plugins. All entries in the CA are listed as add on "15.08.2024". I see entries that are months old on the first page of the recently added tab.

Hey guys, since the new version i receive this message now from fix common problems: Jul 5 04:47:30 Tower root: Fix Common Problems: Error: Old version of SSD Trim Schedule According to the changes i guess this has something to do with this: Added: Check for incompatible cron file created by Dynamix SSD Trim plugin But i dont have that plugin installed. How am i supposed to fix this issue now?

Hey guys, i might have found a bug. Not sure though. So i was trying to build this project: https://github.com/ZeppelinBot/Zeppelin/tree/b28ca170edc39ec2248801c50bb42c2d2411f5f5 using this documentation https://zeppelin.wiki/setup/operating-systems/linux-docker It is important to run git checkout b28ca17 after git clone command. I renamed the docker-compose.standalone.yml to docker-compose.yml and the .env.example to .env. I added a docker compose project to the cloned folder and configured the docker-compose.yml to be the newly renamed one. All looked good. When i started the project, i noticed, that somethign was odd and that it was trying to read the 3 other .yml files aswell. I also noticed, that the migrate container was not buioldign and running. I only got this fixed, after deleting all three additonal .yml files and leaving only the renamed docker-compose.yml behind. So i assume, there is some kind of bug in the docker-compose plugin, or in docker-compose it-self, that results in loading the additional .yml files (for whatever reason) and tries to run them or so. I am really not sure.

Thanks for the answer. Imo it makes sense, how its done atm according to your explanation, but i (and probably others) still think, that the script should be run as is and let the user implement their ways of signal handling using trap and such things. That would make that feature easier to understand and use in my opinion. I am not sure if most people know, that if you abort a background script, the script actually doesnt really "abort". Ofc changing that would be quite a hassle, but it makes the feature quite hard to use manually, when you have to run a long lasting command and want to interrupt it if needed.

I mean, if you run a script in foreground, you can close/stop it and the processes stop aswell and i would think that if you run it in background and you abort it, the same would happen. Atleast from searching this topic for this "issue" others seem to think the same. Abort should stop the script and the execution of any processes

I mean, that makes kinda sense, but why doesnt userr scripts "simply" run the scripts itself? Wouldnt that make more sense? Aborting would then send a sigterm/sigkill/whatever signal to the script, which the script could handle. Imo that would make way more sense, atleast imo

Yes, but this cant be intended behaviour. Why would you want to abort a background script, just for the processes in the background to keep running. Imo this doesnt make much sense. But maybe @Squidcan give his opinion on this and maybe clarify it.