SRB

I was getting upload errors to Nextcloud, consistent with what everyone is reporting here. Unclear if it was the update to MariaDB, Unraid 6.12 or the combination of the both that broke everything. Either way, I was able to fix everything through the following steps. 1. Update MariaDB to the latest docker version. Check the docker log, and if you see the message @silentbob noted, perform the upgrade. 2. Restart MariaDB and Nextcloud dockers. Try to upload a document to Nextcloud. In my case all uploads were failing (both through browser and desktop client). My Nextcloud log (which you can check at Administration setting > Logging on your Nextcloud site) was filled with Doctrine\DBAL\Exception\DriverException: An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1034 Index for table 'oc_filecache' is corrupt; try to repair it so I figured I needed to repair the oc_filecache table in my MariaDB nextcloud database. 3. Stop the Nextcloud docker or put it into maintenance (unsure which is best practice, maybe some from the LS team can chime in) docker exec -it nextcloud occ maintenance:mode --on 4. Access your MariaDB container's console and truncate your oc_filecache table. Be careful, there is no heading back from this. I believe you will lose all file shares and labels (metadata type stuff). docker exec -it mariadb bash mysql -u root -p<ROOTPASSWORD> USE <NEXTCLOUDDB>; TRUNCATE TABLE oc_filecache; 5. Restart your Nextcloud docker or take it out of maintenance mode docker exec -it nextcloud occ maintenance:mode --off 6. Run the occ files:scan command to rebuild your file cahce. This could take a while (especially if you have a big install). The webgui may be unresponsive, just let it run and everything should eventually come back. docker exec -it nextcloud occ files:scan --all -vvv

Nvm... one of my cached disks had dropped out making all shares that use it unwrittable 🤦‍♂️

Hey everyone, I noticed this morning that my Nextcloud clients were not connecting (everything was working fine yesterday). I went to the webgui and got this message Your data directory is not writable Permissions can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/23/go.php?to=admin-dir_permissions. From reading around I need to run a chown command on the nextcloud data directory (/data within the docker, /mnt/user/nextcloud in unraid). I'm just unsure what the command should be. Who is the user that should have write permissions? the unraid nobody user? abc user in nextcloud docker? should the command be run from unraid bash or from within the docker? Thanks

Interesting. Thanks for the suggestions. Fairly certain its not the mini sas cable they share since I've replaced it, but I hadn't considered the PSU and/or power splitter. I'll have to investigate.

Hey everyone, Looking for advice on next steps on how to deal with some disk errors I have been fighting with. About a month ago I had one disk report read errors, and so I did the usual pull bad disk, replace with known good disk and rebuild. This was followed by another that did the same, so I pulled it and rebuilt with another known good disk. Everything rebuilt fine and all was good. I always do a pre-clear postmortem on bad disks to confirm they are unreliable. However, this time 3 cycles of preclear on each disk reported that these disks were still good. This worried me, as I wondered if the issue could then be with the cabling or HBA. And of course, this issue reared its ugly head again on the same disk slots, even though the disks were new and pre-tested (I always do 3 rounds of preclear before putting a disk into the array). So I swapped the HBA and got new cables. Everything rebuilt fine and I ran a parity check immediately after, which passed with zero errors. But I wouldn't be posting here if the issue didn't persist. Today I got read errors again on the same two disks, both at the same time. No data loss (thank goodness for dual parity), but I'm at a loss on next steps for troubleshooting. Attached is the diagnostics zip file with the most recent round of disks errors captured (disks 13 and 14, sds and sdv). Any suggestions on what to try next would be greatly appreciated. jt-diagnostics-20210913-1333.zip

Just recently, I am getting errors when trying to connect to certain indexers in Sonarr/Radarr when going through this container's Privoxy. Some indexers work, and some don't (I've found that Rarbg and NzbFinder.ws don't). Disabling the proxy in Sonarr/Radarr fixes the issues. Any ideas on what might be causing this? The Sonarr logs just give a generic protocol error Unable to connect to indexer: Error: ProtocolError: 'https://nzbfinder.ws/...'

Excellent, thanks for the clarification

I had the same question as I switched from PIA to Mullvad. I think I have port forwarding setup correctly as I am seeing a big improvement in speeds after I did the following: 1. Got a port assigned from Mullvad (My Account > Manage ports and WireGuard keys > OpenVPN Forwarded Ports) 2. Stop and modify DelugeVPN docker container. Everything stayed the same from my PIA configuration, except: VPN_user: [Mullvad account #] VPN_pass: m VPN_PROV: custom STRICT_PORT_FORWARD: no (only required for PIA) 3. Download ovpn file and crt file from Mullvad. Placed these in the delugeVPN\openvpn appdata folder. Renamed the ovpn file to openvpn.ovpn and make sure it points correctly to the mullvad crt file. 4. Start container. Check docker container log to make sure VPN connection is established correctly. Once webgui is up and running go to Preference > Network. In Incoming Port, untick Use Random Port (if it was ticked) and in the box put the Mullvad assigned forwarded port. Hit Apply and Ok. 5. Restart docker, just in case/for fun. 6. Go to https://www.yougetsignal.com/tools/open-ports/. Enter your VPN server's public IP address (can get it from the container log) and the Mullvad assigned port, the port should come back as open. You can also test by downloading a popular torrent (ubuntu image for example) and seeing what speeds you get. I was getting 30 MB/s after doing all this so I was confident it was working correctly.

Hey everyone, Hoping I can get some help with pfSense running as a VM within Unraid. The VM has been freezing causing all network traffic to die, and it all stems from this error in the pfSense syslog Nov 18 10:52:47 kernel calcru: runtime went backwards from 2843 usec to 1269 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2831 usec to 1268 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2689 usec to 1200 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2957 usec to 1322 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2739 usec to 1224 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2815 usec to 1257 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 3096 usec to 1384 usec for pid 0 (kernel) Nov 18 10:52:47 kernel calcru: runtime went backwards from 2867 usec to 1281 usec for pid 0 (kernel) which according to this post on the Netgate forums (https://forum.netgate.com/topic/51494/runtime-went-backwards) is related to a NTP conflict between the hypervisor and pfSense. Does anyone know how I can stop Unraid from setting the VMs time via NTP? Thanks tower-diagnostics-20191118-1109.zip

Changed Status to Closed

Done and fixed. Thanks. Not sure what caused it because I don't have any VMs on this machine.

I struggled with InvoiceNinja as a docker for a while, never got it to work and so decided to run it as an Ubuntu VM. Been running smoothly for over 6 months now and I have no complaints. Followed this guide to get it up and running: https://websiteforstudents.com/install-invoice-ninja-on-ubuntu-16-04-18-04-lts-with-nginx-mariadb-and-php-7-2-fpm/ Did a little bit of customizing to get it to work with the Linuxserver letsencrypt docker, which I'd be happy to share if anyone is interested.

One issue I've noticed after point unmanic to my entire tv shows library is that the dashboard page becomes unresponsive. Tested on both firefox and chrome. I've queued up several hundred jobs, all of which are trying to be displayed on the dashboard which the browser cannot handle. The conversions continue on just fine and the work around is to check progress on the history page.

Here is an updated/alternate icon for pfSense