DDock

Recently started having issues after upgrading to 6.12.2 where Sonarr/Radarr will stop moving files from qBittorrent. I've had this setup running for a couple years now without issues. All dockers are up to date Binhex versions. I have a spare drive mounted via Unassigned Devices used as a scratch disk to download files from qBittorrent as not to put extra write cycles on my Cache SSDs. qBittorrent is installed natively to this scratch disk and then Sonarr/Radarr are installed on my Cache SSDs. I have tried changing the Access Mode to various RW/Slave/Shared between them all and nothing seems to work. I had first changed it all to RW-Slave as Fix Common Problems didn't like that those were mounted using RW and not RW-Slave. I've checked all kinds of things and can't seem to get Sonarr to work. I think Radarr is working, but hasn't been queued to download anything recently. No other connection errors between the dockers. Is there something I'm missing? Thanks for any help the community can provide.

We have used Cloudberry at work for awhile and they have now rebranded over to MSP360. They are concentrating on MSP's at this point. This might be what you guys are looking for: https://www.msp360.com/free-products/ I have gotten the Linux licenses from here and setup new unRAID backups since.

Thank you. I didn't see the update still, so I forced update and BAM, now it finally got updated to the 3.3.xx. Not sure why it wasn't showing updates, but we are all good now. Thank you again.

I am having an issue with a new install of Cloudberry Backup. It ran fine for a few days and now whenever it tries to backup I get a SSL Cert Problem; Cert has expired error. I did try to contact Cloudberry support, but they told me that I need to update. I tried to run the update from within the docker using the webGUI, but it seems to try but then gets stuck updating until I reboot the docker container. I did see a mention from a month ago that you were working on updating to the 3.2.xxx version. Is there any progress on this? Is there something I could do to assist?

I have been having an odd issue I've noticed from time to time. My CPU will just go crazy. Looking into it it seems the process that is repeated many times is "/usr/bin/sha256sum -b /mnt/.....". The file that is being crunched on is a file being downloaded by my binhex-qbittorrentvpn docker. If I stop / restart the docker this process still does not go away. I am wondering if it might be dealing with the File Integrity plugin I have. I added the share to File Integrity's ignore list but it is still crunching away on the files. I plan on doing some work to my server this weekend, so at this point I have not restarted since I made the changes to the File Integrity plugin, but wanted to get so input. A second thing I found while trying to track this down was this error in the syslog and want to make sure it isn't something I should be concerned with. I haven't had issues with USB, but I don't really use the USB on the server. My DNS update script ran between these entries which is set to run every 5 minutes to update the IP for my domain. This repeats regularly though the log. Oct 23 04:44:02 Tower kernel: usb 2-5: reset high-speed USB device number 3 using xhci_hcd ### [PREVIOUS LINE REPEATED 170 TIMES] ### Oct 23 04:49:02 Tower kernel: usb 2-5: reset high-speed USB device number 3 using xhci_hcd ### [PREVIOUS LINE REPEATED 149 TIMES] ### tower-diagnostics-20201023-0955.zip

Yep! must have been a bug. Thanks. Had me a bit worried that you might have discontinued the project or something. Cheers and thanks for all the hard work!

Any ideas why this is showing up for this docker? None of my other dockers show this: I have not made any changes but noticed this has changed to not available. I haven't checked things in about a week, so it would have happened between then and now.

I recently upgraded from a single 1TB SATA to 2 1TB NVME M.2 SSDs and switched to using a cache pool for my new server upgrade. First I added 1 of the NVME drive's to the cache and it created the cache pool. I waited for the balance to finish and everything looked fine. I then removed the SATA SSD and replaced it with the second of the NVME SSD's and everything rebuilt and seemed fine... Today I shut down the server and removed the old SATA SSD that was listed in unassigned devices and my cache pool broke. The first drive in the cache shows up as Unmountable: No file system. I started looking around and ultimately decided to just throw the SATA SSD back in as an unassigned device, and voila everything is working again. What the heck is happening? I did initiate a btrfs Balance to see if that fixes it. It is currently running. I don't actually recall a balance happening after replacing the SATA SSD with the second NVME SSD. Any other thoughts?

Just to make sure I'm running the proper command I'm just deleting the attribute user.sha256 and not the other user.xxx attributes? Thank You for sending me down the correct path.

I'm having an issue that since I installed the plugin again like 1-2 months ago. I had used this plugin a long time ago and decided to install it again. It has consistently shows 5 files that are corrupted ever since I reinstalled it. Not sure if these are because there were some files left behind from the previous install of this plugin. 4 of them are just NFO's and one is an MKV. Is there a way to acknowledge the error so it stops reporting it or what is the best way to handle it.

I can't seem to find a way to search this thread. I haven't done much posting recently. I just added this plugin to my 6.5 unRAID server. I am having some issues with a VM that runs my Security Camera Software. I am thinking the issue is the slower write speeds to the array so I am wanting to offload the VM onto a single mount. All seems to be working well with the exception that my Shares in the normal unRAID GUI are not showing up. Any thoughts?

Still having the issue.

Any suggestions?

Here is the log after I hit join: Jan 18 15:45:30 AscotBackup emhttpd: req (14): DOMAIN=corp.ascotent.com&DOMAIN_SHORT=corp&DOMAIN_LOGIN=Administrator&DOMAIN_PASSWD=*****&cmdJoinDomain=Join&csrf_token=***** Jan 18 15:45:40 AscotBackup emhttpd: Stopping services... Jan 18 15:45:40 AscotBackup emhttpd: shcmd (1293): /etc/rc.d/rc.libvirt stop Jan 18 15:45:40 AscotBackup root: Waiting on VMs to shutdown Jan 18 15:45:40 AscotBackup root: Stopping libvirtd... Jan 18 15:45:40 AscotBackup dnsmasq[22595]: exiting on receipt of SIGTERM Jan 18 15:45:40 AscotBackup kernel: device virbr0-nic left promiscuous mode Jan 18 15:45:40 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered disabled state Jan 18 15:45:40 AscotBackup avahi-daemon[3940]: Interface virbr0.IPv4 no longer relevant for mDNS. Jan 18 15:45:40 AscotBackup avahi-daemon[3940]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Jan 18 15:45:40 AscotBackup avahi-daemon[3940]: Withdrawing address record for 192.168.122.1 on virbr0. Jan 18 15:45:41 AscotBackup root: Network 7b78fb65-4fac-44d5-9754-39482f1311f9 destroyed Jan 18 15:45:41 AscotBackup root: Jan 18 15:45:44 AscotBackup root: Stopping virtlogd... Jan 18 15:45:45 AscotBackup root: Stopping virtlockd... Jan 18 15:45:46 AscotBackup emhttpd: shcmd (1294): umount /etc/libvirt Jan 18 15:45:47 AscotBackup emhttpd: shcmd (1296): /etc/rc.d/rc.docker stop Jan 18 15:45:47 AscotBackup root: stopping dockerd ... Jan 18 15:45:48 AscotBackup root: waiting for docker to die... Jan 18 15:45:49 AscotBackup avahi-daemon[3940]: Interface docker0.IPv4 no longer relevant for mDNS. Jan 18 15:45:49 AscotBackup avahi-daemon[3940]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Jan 18 15:45:49 AscotBackup avahi-daemon[3940]: Withdrawing address record for 172.17.0.1 on docker0. Jan 18 15:45:49 AscotBackup emhttpd: shcmd (1297): umount /var/lib/docker Jan 18 15:45:49 AscotBackup emhttpd: shcmd (1298): /etc/rc.d/rc.samba stop Jan 18 15:45:49 AscotBackup emhttpd: shcmd (1299): rm -f /etc/avahi/services/smb.service Jan 18 15:45:49 AscotBackup avahi-daemon[3940]: Files changed, reloading. Jan 18 15:45:49 AscotBackup avahi-daemon[3940]: Service group file /services/smb.service vanished, removing services. Jan 18 15:45:53 AscotBackup emhttpd: shcmd (1302): /etc/rc.d/rc.nfsd stop Jan 18 15:45:53 AscotBackup rpc.mountd[22077]: Caught signal 15, un-registering and exiting. Jan 18 15:45:54 AscotBackup kernel: nfsd: last server has exited, flushing export cache Jan 18 15:45:54 AscotBackup emhttpd: Starting services... Jan 18 15:45:54 AscotBackup emhttpd: shcmd (1306): chmod 0777 '/mnt/disk1' Jan 18 15:45:54 AscotBackup emhttpd: shcmd (1307): chown 'Administrator':'Domain Users' '/mnt/disk1' Jan 18 15:45:54 AscotBackup root: chown: invalid user: 'Administrator:Domain Users' Jan 18 15:45:54 AscotBackup emhttpd: shcmd (1307): exit status: 1 ---- edited out REPEAT for each mnt ---- Jan 18 15:45:54 AscotBackup emhttpd: shcmd (1333): /etc/rc.d/rc.samba start Jan 18 15:45:54 AscotBackup root: Starting Samba: /usr/sbin/nmbd -D Jan 18 15:45:54 AscotBackup root: /usr/sbin/smbd -D Jan 18 15:45:54 AscotBackup root: /usr/sbin/winbindd -D Jan 18 15:45:54 AscotBackup emhttpd: shcmd (1334): cp /tmp/emhttp/smb.service /etc/avahi/services/smb.service Jan 18 15:45:54 AscotBackup avahi-daemon[3940]: Files changed, reloading. Jan 18 15:45:54 AscotBackup avahi-daemon[3940]: Loading service file /services/smb.service. Jan 18 15:45:55 AscotBackup avahi-daemon[3940]: Service "AscotBackup" (/services/smb.service) successfully established. Jan 18 15:45:58 AscotBackup emhttpd: shcmd (1337): /etc/rc.d/rc.nfsd start Jan 18 15:45:58 AscotBackup root: Starting NFS server daemons: Jan 18 15:45:58 AscotBackup root: /usr/sbin/exportfs -r Jan 18 15:45:58 AscotBackup root: /usr/sbin/rpc.nfsd 8 Jan 18 15:45:58 AscotBackup root: /usr/sbin/rpc.mountd Jan 18 15:45:58 AscotBackup rpc.mountd[23863]: Version 2.1.1 starting Jan 18 15:45:59 AscotBackup emhttpd: shcmd (1346): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 20 Jan 18 15:45:59 AscotBackup kernel: BTRFS info (device loop2): disk space caching is enabled Jan 18 15:45:59 AscotBackup kernel: BTRFS info (device loop2): has skinny extents Jan 18 15:45:59 AscotBackup root: Resize '/var/lib/docker' of 'max' Jan 18 15:45:59 AscotBackup kernel: BTRFS info (device loop2): new size for /dev/loop2 is 21474836480 Jan 18 15:45:59 AscotBackup emhttpd: shcmd (1350): /etc/rc.d/rc.docker start Jan 18 15:45:59 AscotBackup root: starting dockerd ... Jan 18 15:46:00 AscotBackup avahi-daemon[3940]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Jan 18 15:46:00 AscotBackup avahi-daemon[3940]: New relevant interface docker0.IPv4 for mDNS. Jan 18 15:46:00 AscotBackup avahi-daemon[3940]: Registering new address record for 172.17.0.1 on docker0.IPv4. Jan 18 15:46:00 AscotBackup kernel: IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready Jan 18 15:46:02 AscotBackup emhttpd: shcmd (1358): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Jan 18 15:46:02 AscotBackup kernel: BTRFS info (device loop3): disk space caching is enabled Jan 18 15:46:02 AscotBackup kernel: BTRFS info (device loop3): has skinny extents Jan 18 15:46:02 AscotBackup root: Resize '/etc/libvirt' of 'max' Jan 18 15:46:02 AscotBackup kernel: BTRFS info (device loop3): new size for /dev/loop3 is 1073741824 Jan 18 15:46:02 AscotBackup emhttpd: shcmd (1366): /etc/rc.d/rc.libvirt start Jan 18 15:46:02 AscotBackup root: Starting virtlockd... Jan 18 15:46:02 AscotBackup root: Starting virtlogd... Jan 18 15:46:02 AscotBackup root: Starting libvirtd... Jan 18 15:46:02 AscotBackup kernel: tun: Universal TUN/TAP device driver, 1.6 Jan 18 15:46:02 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered blocking state Jan 18 15:46:02 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered disabled state Jan 18 15:46:02 AscotBackup kernel: device virbr0-nic entered promiscuous mode Jan 18 15:46:03 AscotBackup avahi-daemon[3940]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Jan 18 15:46:03 AscotBackup avahi-daemon[3940]: New relevant interface virbr0.IPv4 for mDNS. Jan 18 15:46:03 AscotBackup avahi-daemon[3940]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Jan 18 15:46:03 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered blocking state Jan 18 15:46:03 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered listening state Jan 18 15:46:03 AscotBackup dnsmasq[24397]: started, version 2.78 cachesize 150 Jan 18 15:46:03 AscotBackup dnsmasq[24397]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify Jan 18 15:46:03 AscotBackup dnsmasq-dhcp[24397]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Jan 18 15:46:03 AscotBackup dnsmasq-dhcp[24397]: DHCP, sockets bound exclusively to interface virbr0 Jan 18 15:46:03 AscotBackup dnsmasq[24397]: reading /etc/resolv.conf Jan 18 15:46:03 AscotBackup dnsmasq[24397]: using nameserver 192.168.100.236#53 Jan 18 15:46:03 AscotBackup dnsmasq[24397]: using nameserver 192.168.100.235#53 Jan 18 15:46:03 AscotBackup dnsmasq[24397]: read /etc/hosts - 2 addresses Jan 18 15:46:03 AscotBackup dnsmasq[24397]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Jan 18 15:46:03 AscotBackup dnsmasq-dhcp[24397]: read /var/lib/libvirt/dnsmasq/default.hostsfile Jan 18 15:46:03 AscotBackup kernel: virbr0: port 1(virbr0-nic) entered disabled state

I have now restarted our Main and Backup DC's. I can ping both of them using their FQDM using the new built in terminal in the webui. The DNS in unRAID is set to (and has been) the two DC's. Still not working.