autumnwalker

I am trying to get Zabbix to monitor my GPU via nvidia-smi (https://github.com/zabbix/community-templates/tree/main/Server_Hardware/Other/template_nvidia-smi_integration/7.0). I've successfully mapped /etc/zabbix/zabbix_agentd.d as a volume and I created my .conf there for UserParameters. I have those working, but I get an error of Value "sh: nvidia-smi: not found" in Zabbix. I suspect this is due to permissions and the container cannot execute nvidia-smi on the server. Any thoughts about how to do this?

Still not working when auto update fires. Any ideas?

Just to report back / confirm - I did a rm -r *.running in each of the virtual machine folders and I did rm -r snapshots.db under /etc/libvirt/qemu/snapshotdb/[machine name]and everything worked as expected. Thank you!

Anyone else having an issue after updating this container (default deployment with the permission fixes from @lifegrasp ) losing the database?

So from terminal I can, for example, rm -r /etc/libvirt/qemu/snapshotdb/Graylog/snapshots.db while the VM is running and also remove the .running files?

virsh dumpxml Graylog | xmllint --xpath '//devices/disk' - -:5: namespace warning : xmlns: URI unraid is not absolute <vmtemplate xmlns="unraid" name="Ubuntu" icon="graylog.png" os="ubuntu" icon ^ <disk type="file" device="disk"> <driver name="qemu" type="raw" cache="writeback" discard="ignore"/> <source file="/mnt/user/virtualmachines/Graylog/vdisk1.img" index="4"/> <backingStore/> <target dev="hdc" bus="virtio"/> <boot order="1"/> <alias name="virtio-disk2"/> <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/> </disk>

It's actually the name of that file "remove\ landscape.running". "remove landscape" was the name of the snapshot. It is the one that I successfully commit before running into the issue with committing "upgrade" and "updates" snapshots.

cat /etc/libvirt/qemu/snapshotdb/Graylog/snapshots.db { "updates-2025-05-30": { "name": "updates-2025-05-30", "parent": "Base", "state": "disk-snapshot", "desc": null, "memory": { "@attributes": { "snapshot": "no" } }, "creationtime": "1748623874", "method": "QEMU", "backing": { "hdc": [ "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.updates-2025-05-30qcow2", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.img" ], "rhdc": [ "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.img", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.updates-2025-05-30qcow2" ] }, "primarypath": "\/mnt\/cache\/virtualmachines\/Graylog", "disks": [ { "@attributes": { "name": "hdc", "snapshot": "external", "type": "file" }, "driver": { "@attributes": { "type": "qcow2" } }, "source": { "@attributes": { "file": "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.updates-2025-05-30qcow2" } } } ] }, "graylog_upgrade_6.2": { "name": "graylog_upgrade_6.2", "parent": "updates-2025-05-30", "state": "disk-snapshot", "desc": null, "memory": { "@attributes": { "snapshot": "no" } }, "creationtime": "1749133567", "method": "QEMU", "backing": { "hdc": [ "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.graylog_upgrade_6.2qcow2", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.updates-2025-05-30qcow2", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.img" ], "rhdc": [ "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.img", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.updates-2025-05-30qcow2", "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.graylog_upgrade_6.2qcow2" ] }, "primarypath": "\/mnt\/cache\/virtualmachines\/Graylog", "disks": [ { "@attributes": { "name": "hdc", "snapshot": "external", "type": "file" }, "driver": { "@attributes": { "type": "qcow2" } }, "source": { "@attributes": { "file": "\/mnt\/user\/virtualmachines\/Graylog\/vdisk1.graylog_upgrade_6.2qcow2" } } } ] } } ls /mnt/user/virtualmachines/Graylog graylog_upgrade_6.2.running remove\ landscape.running updates-2025-05-30.running vdisk1.img*

I've been trying to clean up my snapshots. I understand that I need to "block commit" in most cases (sometimes I can simply delete). I've got a handful of snapshots now on different VMs where I get the following error and I am stumped: virsh blockcommit '[vm name]' --path '/mnt/user/virtualmachines/[vm name]/vdisk1.img' --verbose --pivot --delete /mnt/user/virtualmachines/[vm name]/vdisk1.img: error: invalid argument: could not find base image in chain for 'hdc'. . The command failed.I saw the similar issue in the previous posts, but I don't have USB attached to any of these VMs. The only commonality is that these machines all had multiple snapshots - the first block commit will work, but subsequent fail with this error.

Ah ok, I thought it would run anytime the container was started regardless of method. I'll try having it auto update and see if that makes it work.

Trying to get a script to fire every time I update a container, but it is not working. Any ideas? I have created a file under "/boot/config/plugins/ca.update.applications/scripts/starting/". I used the exact name of the container "zabbix-agent2" (no .sh). I think it is a valid bash script (see script contents below). I have tried with and without "#!/bin/bash" at the start of the script (no difference). When I "apply update" manually from the "Docker" tab, the script does not fire (confirmed as the zabbix agent loses Docker data until I manually run the commands that are contained in the script). docker exec --user root zabbix-agent2 sh -c "addgroup -g 281 docker" docker exec --user root zabbix-agent2 sh -c 'sed -i "s/docker:x:281:/docker:x:281:zabbix/g" /etc/group'

I cannot get this working for the life of me. I have added a script as described, but any time I update the container the script does not apply the commands. I don't see anything in the logs on Unraid or the container itself. Not sure what I am doing wrong.

@jimmy898 can you share the script / how you got this to work? Is this as simple as: #!/usr/bin/bash docker exec --user root zabbix-agent2 sh -c "addgroup -g 281 docker" docker exec --user root zabbix-agent2 sh -c "sed -i "s/docker:x:281:/docker:x:281:zabbix/g" /etc/group"

Try creating a new path variable inside the Docker container configuration - path in container and on host is /var/run/docker.sock. Save it and then do the "add group", "add to groups file" thing, restart container. After I added /var/run/docker.sock to my container config this started working!!

@Rysz thank you for taking this on and for being so active and helpful here in the community. I was working with one of the NUT devs to compile support for Liebert GXT UPS with is-webcard and this older network card I had at the time - we got really close and then he / she fell off the face of the earth so we never quite finished. My UPS mostly works with the ietf MIB. I'm hoping that one of the new NUT builds will incoroporate the work that we did for the Liebert GXT line.

Thank you for the heads up! Is there a way to roll back to a previous version of the plugin if you update and it breaks your UPS? I don't want to get "tech debt" by just letting the updates go.

Is it possible to use this to host local files on TFTP? I have a couple of devices (e.g. IP phone) which are updated via tftp hosted files. I like the iPXE features too ... but wondering if I can also use this to allow a device to grab a local file via tftp without the whole iPXE menu, etc.

Running this version now with SNMP. Appears to be working as designed! Thanks!

Ahh - that shows the localhost stuff - the old version I had network as "no".

Weird ... I don't see it here.

Appears to have worked. Did the configuration for "enable localhost connection" get removed? I don't see it in settings anymore - but I see sensor values from IMPI so it must be working.

Thanks, I'll give this a shot.

I can find it, but when I hit "update" it installs the dmacias72 version again.

hmm - trying to do the "update" method outlined in the early posts, but it just keeps re-installing the old version by dmacias72. Do I have to be on 6.12 first?

Anyone using a reverse proxy and experincing this? I just flipped to Nginx Proxy Manager and experienced this again. Toggling "websockets support" immediately solved the problem in the Unraid dashboard for me.