paddesb

I have a different poolname (and path). I had it simplified to make it easier to read. But thanks for pointing it out To avoid confusion I will change it 🙂

I was able to solve it by changing the file as follows: version: '3.9' services: glftpd: image: jonarin/glftpd container_name: FTPd restart: unless-stopped networks: default: ipv4_address: 10.10.099.243 ports: - 23830-23840 environment: - GL_RESET_ARGS=-e - TZ=Europe/Zurich - GL_PORT=23840 volumes: - '/mnt/myshare/ftp/conf:/glftpd/ftp-data' - '/mnt/myshare/ftp/data:/glftpd/site' networks: default: external: true name: bond0 It's not pretty but it seems to work. If anyone has a better solution please let me know 🙂

@mods: I hope I'm in the right subforum. Seemed to be the most fitting. If not, please send me a pm TL;DR: fresh unraid install (version 6.12.6). trying to get https://github.com/jonathanbower/docker-glftpd to work and failing hard. Unable to get a direct network connection (prefered) and/or mapping on host. Hi guys, I recently (re-)installed a fresh unraid with version 6.12.6 and set up everything up from scratch. No specific in-depth config/tweaks. Everything's rather default. All my previous dockers are working fine except glftpd (the docker I'm using: https://github.com/jonathanbower/docker-glftpd) although using the exact same template as on the previous install. The issue: it doesn't matter if or what network I specify, it won't establish a network connection (I prefer glftpd having its own IP) or map the ports on the host. No errors shown in docker-log. My current network settings: dual-nic bond (active-backup) bridging disabled macvlan enabled My compose file (using the Compose.Manager-Plugin) I used before and was working like a charm version: '3.9' services: glftpd: image: jonarin/glftpd container_name: FTPd restart: unless-stopped networks: bond0: ipv4_address: 10.10.099.243 ports: - 23830-23840 environment: - GL_RESET_ARGS=-e - TZ=Europe/Zurich - GL_PORT=23840 volumes: - '/mnt/myshare/ftp/conf:/glftpd/ftp-data' - '/mnt/myshare/ftp/data:/glftpd/site' networks: bond0: external: true name: bond0 What I tried so far: all combination of bond on/off, bridging on/off, ipvlan/macvlan. but no dice. Previous (working) setup on old install: bond on + bridging on + macvlan (I know, not recommended anymore, but it was a legacy setup and had no issues whatsoever) specifying all available docker networks/-types Since I'm no docker expert in any regard, does anyone have any idea on how to get it (back) working (again) or any hints where to look? Thanks in advance paddesb

yes, i had removed the vcpu-pinning. By adding one via console and rebooting the server, all is fine and well again 🙂 in case someone else needs to know how: nano /etc/libvirt/qemu/<yourvmname>.xml and add/change the settings SimonF mentioned above) Thanks @SimonF! Have to ask though, why did removing the pinning "suddenly" cause the system to not display the settings? it was working perfectly without pinning all these years... 🤔

sure, there you go: cat /sys/devices/system/cpu/*/topology/thread_siblings_list|sort -nu 0,4 1,5 2,6 3,7 Edit: Inspired by your question I just checked if I could edit the vms and interestingly enough edit is only possible for No 2 "WinServ" (although it takes a "longer" minute to load) for "DebServ" the edit screen won't load at all

Hey @SimonF Referring to my earlier post I updated to RC6 (from RC5) as well and the problem persists. I attached the updated diagnostics. Maybe it helps investigating why this is happening. 🤞 virsh list --all Id Name State ------------------------- 1 DebServ running 2 WinServ running Cheers theserver-diagnostics-20230604-1454.zip

yes, I just (completely) deleted the VM right now via the Dashboard and checked /etc/libvirt/qemu for any residual files. As far as I can tell everything's gone but the issue persists. Maybe as a note: this vm was created with ED's macinabox script and there still may be some leftover files I don't know about elsewhere

Hey guys, pardon me for reopening this thread, but I'm having the exact same issue. I just upgraded to 6.12.0-rc5 from 6.11.5 and as far as I can tell, everything seems to be running smooth so far - except the VMs Tab. All the VMs are still there though and can be managed/started from the dashboard. Tried toggling vm-manager off/on and rebooting the server to no avail. 😕 See attached the virsh list and diagnostics # virsh list --all Id Name State --------------------------- 1 DebServ running 2 WinServ running - MacVania shut off Any pointers on how to fix this? theserver-diagnostics-20230505-0154.zip

not exactly sure if this is the correct subforum but same issue here. started ~1h ago @Squid is it an issue with community application or something else?

I'm facing similar issues. after updating the cert via the plugin I'm stuck with "DNS Propagation is PENDING" access to the interface takes "forever" (~10-15s) unable to select "auto" under use SSL/TLS during the cert updating process I saw following error appear real quick "nchan communication error" Any ideas to sort this out? PS: dns rebind has been updated ofc