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.

Unable to join the domain after the upgrade. I double checked the settings and the settings are the same. I set SMB to Yes (Workgroup), restarted, and then set back to Yes (Active Directory), restarted, and still not working. Any thoughts?

Never mind, took about 10 minutes and it started responding again, naturally right after I posted this. Just going to leave for a reference for other people if needed. Mods can delete if they like.

Just downloaded the new update and it is now stuck on this and I am not sure how to proceed. Been sitting this way for awhile now, and the webgui is not responding in a new tab.

Can we get an update to a 5.6.x build so I can patch the WPA2 KRACK. Please and Thank You.

I tried looking for somethings, but not finding anything right now. Is there a way to have other users to remotely start their VMs without having access to the unRAID webui? I have a brother and a friend who have game servers on my unRAID box, but they are those who find a game, play it for a couple weeks and move to something else. Is there a plugin/other utility that I could use to allow them to start their own VMs when they have been shut down. At times they go weeks without using it and I would like to free up some resources when they are not using it. I have a web server that SSL proxy forwards everything including Guacamole in which they use for accessing the VMs.

Alright, Updated the BIOS on 7/22 and today on 7/26 it has become unresponsive again. This time I am able to cp the syslog (unlike the last time), browse directories, but this time I tried to restart the webgui but the process would not complete. Here are the logs from FCP. There were also no errors shown on the CLI. companybackup-diagnostics-20170726-0918.zip FCPsyslog_tail.txt

We have Fix Common Problems installed, so I will try that in the morning. We have a VM that runs some backup software (urBackup, no IMMOU) and a docker (dokuWiki). Maybe I can plan some time to go out there and update the BIOS to see if that works. Thanks for the help, I will keep updating you if I find more.

I guess a bigger question is there a way to make a cronjob or something similar to keep an up to date log written somewhere on the array? Before we have to start pulling hardware, I would like to make sure it isn't something in software causing issues. I run to other unRAID servers and neither of them have issues, so I doubt it is software.

Yea the IPMI interface has a live view that is just like you have a local monitor attached. No errors are showing up on the CLI. This time there was no power outage. We also run two power supplies on the system. Not sure if ECC memory will, but we ran a Memory Test for awhile with no errors. Temps wise, everything is good. With the CPU's, we run a dual CPU motherboard. Chassis, PSU (Dual 800W), and Motherboard are SuperMicro. Have two Intel Xeon E5-2620's with Crucial ECC Memory. Any thoughts on how to start testing the system for a bad motherboard or CPU? Normally we have spares of our consumer gear for testing, but nothing server grade.

Just happened again. This time when I logged in to copy the syslog, it is just sitting there trying to copy the file. Not sure what to do. I am going to let it sit for awhile and see it it eventually copies. Any thoughts?