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.

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

I remember seeing a notification when the 6.7.1 Unraid Nvidia build was released? Maybe I'm misremembering. Either way, I have Unraid update and plugin notifications disable and enabled, respectively, so we'll see if a notification comes through when 6.7.2 Unraid Nvidia is released.

Doesn't a work around for this already exist? In Settings > Notification Settings, set Unraid update notification to never check. Then make sure the Plugin update notification is set to something other than never check, since I'm assuming the notifications sent by Unraid Nvidia are considered 'plugin notifications', right @CHBMB?

After the update, I am still getting the same ffmpeg convert error on certain files. Let me know if there are any debugging steps/logs I can provide that can help.

What Boniel said. /mnt/disks is from UD, I'm using it to mount my TV share on my main Unraid box through NFS. I've wavered back and forth between using /mnt/cache and /mnt/user for my appdata folder since I usually always have it set to cache only. But that one time I switched it to use the array and didn't clean up the references to /mnt/cache, oh man the headaches...

The template hasn't been setup right, so you have to map the variables, paths and port yourself. The following (adjusted to your specific setup) should get you started

I'm getting errors with some of my video files. I haven't been able to pin down what exactly is causing the issue, since I can't gain any useful insight from the logs, but its fairly pervasive across my video collection (for a given TV show, maybe one third of episodes error out). I thought maybe it was a permissions issue, so I isolated a few files that were giving me errors and modified their permissions, but this didn't solve the issue. I thought maybe the files were corrupt or something, but I can successfully process them in say a Handbrake docker. Here is an example error I get. ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- **** [base-ubuntu] (hosts_config) Updating hosts file **** [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... **** (permissions_config) Settings permissions **** [cont-init.d] 20-config: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [I 190610 09:27:48 web:2162] 200 GET /?ajax=pendingTasks&format=html (10.8.0.6) 3.51ms [I 190610 09:27:48 web:2162] 304 GET /?ajax=workersInfo (10.8.0.6) 1.02ms [I 190610 09:27:48 web:2162] 304 GET /?ajax=historicalTasks&format=html (10.8.0.6) 28.46ms [I 190610 09:27:50 web:2162] 200 GET /?ajax=pendingTasks&format=html (10.8.0.6) 2.89ms [I 190610 09:27:50 web:2162] 304 GET /?ajax=historicalTasks&format=html (10.8.0.6) 27.36ms [I 190610 09:27:50 web:2162] 200 GET /?ajax=workersInfo (10.8.0.6) 0.58ms 2019-06-10T09:27:53:ERROR:Unmanic.Worker-1 - [FORMATTED] - Exception in processing job with Worker-1: - ['ffmpeg', '-y', '-i', "/library/America's Got Talent - S13E01 - Auditions 1.mkv", '-hide_banner', '-loglevel', 'info', '-strict', '-2', '-map', '0:0', '-map', '0:1', '-map', ' 0:1', '-map', '0:2', '-c:v', 'libx265', '-c:a:0', 'copy', '-c:a:1', 'aac', '-b:a:1', '256k', '-ac', '2', '-metadata:s:a:1', "title='Stereo'", '-c:s:1', 'copy', '-y', "/tmp/unmanic/file_conversion-1560173267.6531262/America's Got Talent - S13E01 - Auditions 1-1560173267.653139.mp4"] Traceback (most recent call last): File "/app/lib/worker.py", line 134, in run self.process_task_queue_item(self.task_queue.get_nowait()) File "/app/lib/worker.py", line 119, in process_task_queue_item self.current_task.success = self.process_item() File "/app/lib/worker.py", line 103, in process_item ffmpeg_args) File "/app/lib/ffmpeg.py", line 509, in convert_file_and_fetch_progress raise FFMPEGHandleConversionError(command) lib.ffmpeg.FFMPEGHandleConversionError: ['ffmpeg', '-y', '-i', "/library/America's Got Talent - S13E01 - Auditions 1.mkv", '-hide_banner', '-loglevel', 'info', '-strict', '-2', '-map', '0:0', '-map', '0:1', '-map', ' 0:1', '-map', '0:2', '-c:v', 'libx265', '-c:a:0', 'copy', '-c:a:1', 'aac', '-b:a:1', '256k', '-ac', '2', '-metadata:s:a:1', "title='Stereo'", '-c:s:1', 'copy', '-y', "/tmp/unmanic/file_conversion-1560173267.6531262/America's Got Talent - S13E01 - Auditions 1-1560173267.653139.mp4"]

Just wanted to show my support for this docker, really fantastic work. I have it setup on my 2nd Unraid machine, processing my main media shares which I pass into the docker using the unassigned devices plugin and NFS. Works beautifully. Keep up the good work.

Thanks Gacpac, I was getting the same warning and this fixed it.

A while ago (unRAID 6.3 days) I was trying to get my server configured to connect to an enterprise proxy for http traffic. Through discussions with LimeTech support, I was advised to add the following to my go config file http_proxy=http://proxyserver:port /usr/local/sbin/emhttp & which is also advised in this thread: Back then it didn't end up working and I was told to wait for the release of unRAID 6.4 since the front-end http server was being changed to nginx. So now that some time has passed I'd figure I'd give it another go, but alas I am still not able to get it working. What's more, I know this is a configuration issue within unRAID because if I create a Win10 VM within unRAID, I can get traffic through the proxy within Windows. Any suggestions on how I can get this working within unRAID? Thanks.

It appears that my plex container has lost its connection to the internet. After noticing I couldn't access my server through the web app, I rebooted the container through the unraid gui, where it just hangs at [cont-init.d] 10-adduser: exited 0. [cont-init.d] 30-dbus: executing... [cont-init.d] 30-dbus: exited 0. [cont-init.d] 40-chown-files: executing... [cont-init.d] 40-chown-files: exited 0. [cont-init.d] 50-plex-update: executing... Atempting to upgrade to: 1.12.2.4929-29f6d1796 I went into the container itself to see what was up, and found that the last command run was a wget to grab the latest release, however the command never completes. To make sure it wasn't a larger problem, I tested the same wget command outside of the container, which runs just fine. Did something change with the network settings for the container? I haven't touched them in forever (i.e., years). Right now they are

I suppose if I wanted to enforce this, in a way that is fair and avoids squabbles, I'd create a policy of BYOD, Bring Your Own Disk! Then each one uses and writes *only* to their disk. If they want more space, they buy a bigger disk, and replace theirs. No one ever has to deal with anyone else's greed or clutter. This doesn't preclude having other shared spaces, if you choose. To avoid fights, it's always best for each shared space to have only one owner, one 'ruler'. Their space, their rules, even if shared access. True, that would be an excellent way to enforce it. However SATA connections in the system are too valuable to give each roommate their own disk. Much more efficient to throw one large disk in and then split it evenly among the squabblers.

Bumping this as this would be a feature I would use immediately. I'll give you my use case: Server serves media (TV shows and movies) to myself and three other roommates. In addition, we each have our own personal (SMB) user shares that we use for personal data (backups, photos, etc...). To keep things fair, setting a size limit for these shares would be beneficial so that one individual cannot hog the array's capacity. In a perfect world I would just condition my roommates to practice restraint and not throw tons of junk in their personal folders, but you know people can be stupid and/or greedy. I've read around the forums extensively about how this could be done by limiting a share to a disk, but I don't have equal disks of a reasonable size to devote to this cause. I've also seen suggestions to try splitting a disk into a few virtual partitions, but failed to find anyone who implemented it in a bulletproof way. Cheers