jbrodriguez

yea, self signed certificates wont work anymore with the app, there are restrictions both in android and ios that make this less than optimal and insecure from the app perspective however, you don't need to be signed in to unraid connect to provision the letsencrypt certificate

it seems you set up ssl on your server, the only supported way to connect is by provisioning a let's encrypt certificate, self signed certificates will not work (as mentioned in this post) https://forums.unraid.net/topic/51332-plugin-controlrd/?do=findComment&comment=1459304 - If you access your server via SSL (https), the app will only connect to the `*.myunraid.net` URL, which is backed by a certificate provisioned via Let's Encrypt (certificate_bundle)

aaahhh finally, the config file !!! ill publish the plugin pointing to the correct location of the config file, but im not sure that will solve your specific case ill look into it this weekend, i have more info now thank you !!!

the plot thickens 🤔 ok, i'll troubleshoot tomorrow, strange stuff though oh, one thought ... in your /var/local/emhttp/myservers.cfg, do both hashes appear ? the correct one 192-168-1-20*.myunraid.net and the "incorrect" one ... 10.253.0.1*.myunraid.net ?

actually, im rereading the code and the config file is at /boot/config/plugins/nut-dw/nut-dw.cfg do you have that file ?

ah, now the purpose of /etc/nut/ups.conf is clearer i assume the web interface for the nut plugin does show the ups info correctly right ? its strange though that the /usr/bin/upsc command is still failing i think it's failing because of the "ups" name ... is there a name entry in your /etc/nut/ups.conf file ? if there is, does it work when you replace it in the command ? /usr/bin/upsc "<name from /etc/nut/ups.conf>@192.168.254.5"

right, i see that file in the plugin code, doesn't seem to be used elsewhere though, however i havent looked too deep still, the code does look for the main config at /boot/config/plugins/nut-dw/nut.cfg i understand /boot/config/plugins/nut-dw/nut.cfg doesn't exist in your system right ? the other 2 commands i sent you, are they throwing the same error as the initial one ? with single quotes /usr/bin/upsc '[email protected]' with double quotes /usr/bin/upsc "[email protected]" thanks for the help in troubleshooting, hopefully we can get to the bottom of it

that's weird, the nut plugin code is reading the config from /boot/config/plugins/nut-dw/nut.cfg, can you confirm you're using the latest nut plugin ?

thank you, can you try /usr/bin/upsc '[email protected]' if that doesnt work /usr/bin/upsc "[email protected]" finally, would you mind sending me your /boot/config/plugins/nut-dw/nut.cfg ? im not sure why the plugin cant parse it, would like to fix the parsing if possible

i see, can you provide the output of /usr/bin/upsc [email protected]

cool, can you do cat /var/log/controlrd.log and post that log (anonymize any private info you want, send me a dm if you prefer)

they should be in the main tab for the server, to the right of the status, cpu load, etc.

release controlrd 2024.08.30, which should support the new nut plugin. i checked the code for the new nut plugin, the core binary is the same, so the output should be the same (unless there are some upstream changes) if you're usingthe nut plugin, let me know if this now works for you

it also depends on your source disks, if they have some hardware issue, copying will also be slow but mostly what mam59 mentioned, if you have other services reading from the source and/or writing to the source/target disks, it will result in a slower operation and unpredictable results, if writing to the same disks involved in the operation

yes, ill focus on ups support now that the core of the new plugin is done, there's a new nut plugin, ill be adding support for it (prob over the weekend)

thanks for the report !!! ok, can you check the following - do a cat /var/log/controlrd.log it will show the host (the *.myunraid.net url) does that match the URL in the Settings > ManagementAccess page ? let me know, to keep troubleshooting

hello all, the ControlR plugin is now controlrd !!! check the post in the plugin thread this release enables quite a lot of improvements: - Open Source: the controlrd plugin is now open source, with an AGPL license 🙌 - Access: the plugin api is now accessed via the Unraid url, no need to set a port anymore - Versioning: no more "v" prefix for the version name - Performance improvements this will be paired with a change in the ControlR mobile app (to be released very soon), which will now have the following requirement - If you access your server via SSL (https), the app will only connect to the `*.myunraid.net` URL, which is backed by a certificate provisioned via Let's Encrypt (certificate_bundle) Finally, the current ControlR plugin will be deprecated

hello all, the ControlR plugin is now controlrd !!! this release enables quite a lot of improvements: - Open Source: the controlrd plugin is now open source, with an AGPL license 🙌 - Access: the plugin api is now accessed via the Unraid url, no need to set a port anymore - Versioning: no more "v" prefix for the version name - Performance improvements this will be paired with a change in the ControlR mobile app (to be released very soon), which will now have the following requirement - If you access your server via SSL (https), the app will only connect to the `*.myunraid.net` URL, which is backed by a certificate provisioned via Let's Encrypt (certificate_bundle) Finally, the current ControlR plugin will be deprecated

i've never seen rsync change the timestamp on a file it's reading, can't really help there 🤷‍♂️

definitely weird, i can't think of a way that rsync would modify a filestamp while reading a file, unbalanced eventually deletes files on the source disk (if doing a move), but if there's an error like the one you posted ("operation flagged" in the logs), then it won't touch the file either it would seem it's a hardware issue, i/o errors on a disk are somewhat difficult to surface, however im not an expert as to suggest ways to test/confirm 🤷‍♂️

for some reason require_once($docroot."/webGui/include/Helpers.php"); doesn't work for me had to do require_once("/usr/local/emhttp/webGui/include/Helpers.php"); not very robust, but not sure why it wouldn't work otherwise 🤷‍♂️

hi, im trying to run a php file via a post to the endpoint POST https://<server>/plugins/controlr/include/Api.php Api.php is very simple <?php require_once($docroot."/webGui/include/Helpers.php"); shell_exec("/usr/bin/logger working -t testing"); ?> but this never gets logged i've `chmod +x Api.php` yet, im receiving a 500 seemingly from nginx i know i can access the /plugins path, since i do that for the unassigned devices plugin (which works normally, i receive a 200 on its endpoint) i haven't properly installed the plugin from a tgz, i just copy Api.php to the folder any thoughts on what i could check ? p.s.: im also authenticating properly and sending the csrf_token

if in use means reading that data, it will work (although slower) if it means writing to it, the results will be unpredictable

i see, yes, thank you, that helps

had to whitelist `myunraid.net` re: dns rebind protection