Porkey

I had to manually create & pass volumes for event_clips, thumbnails, snapshots, & segments, then the container started working. I had to delete a bunch of variables from the template when I created the container (they didn't apply to me), but I swear none of these paths were in the default template... I can't tell if the recordings volume is actually even used for anything in this image; the container doesn't auto-create the missing volumes within the recordings directory. But I got the container to start, and once I got my cameras to behave, they were visible through the Viseron webUI.

Tried again tonight, actually set the permissions to 0750 instead of u=rwx,g=rx; cd to appdata/Viseron folder chmod -R 0750 ./postgresql I think the problem before was that I was trying to chmod -R 750 ./postgresql, I didn't know you could use four digits. Now it's 2025-06-06 05:46:04.638 [ERROR ] [viseron.components] - Error validating config for component storage: The /event_clips folder does not exist. Please mount it to the container.. Got {} I've mounted everything in the template... Is it not creating its own directories, or is one dir missing in the template? I'll try to figure it out tonight, maybe...

FATAL: data diractory "config/postgresql" has invalid permissions No, I'm pretty sure it doesn't. DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750). Setting the permissions as requested had no effect. 777 should work, but the container still wouldn't start postgresql. Tried setting PUID & GUID 99 & 100, still broken. Privileged does not work. I think this is due to the fact that Unraid has nonstandard use of PUID & GUID values? I still don't fully grasp how permissions work on Unraid, especially with dockers. This isn't the first container I've had permissions issues with where there shouldn't be any (the other was MineOS-node). The container's icon also appears to be broken. I can see in the template xml file that it's pointing to a .svg file, but the icon is broken in the Unraid webUI. Other containers with working icons are all raster images. (Does Unraid not support .svg docker icons yet..? Should we add this as a bug report or feature request?)

I'm thinking of using this container as a farmer. The port mappings look a little different. The default port that farmers seem to want is 8447, but I don't see that port opened in the container's config, only 8444 and 8555. Will I need to open another port or change the port in the harvester config?

I installed one of the plugins for my server, and so far things seem to have improved, but the docker container I'm playing with will still throw errors randomly. Docker updates still hang on initial file fetches, but not for as long, and it no longer locks up the webUI (as far as I can tell). Once actual download starts, the files actually seem to download at a much faster speed (current Unraid UI doesn't show actual download speed, just % of layer downloaded). I had to install the plugin manually, since the Community Applications page would just glitch and not do anything when I clicked "install" on the CA app. I downloaded the file from the github repo to my Windows machine; https://raw.githubusercontent.com/jinlife/unraid-r8125-r8152-driver/main/unraid-r8168.plg Then manually moved that file to the NAS's plugin folder over the network. \\server\flash\config\plugins I suppose I could have remoted into the NAS and used wget to put the file there manually, too. According to some forum posts from around the internet (including the Unraid forums), some changes were made recently to the Linux kernel that have messed with some Realtek network drivers, which explains why I didn't notice these problems until "a few OS updates ago." Of course I minded my own business and didn't see the recent commotion around these drivers; it was working fine for years, why should I suddenly have to worry about troubleshooting things and messing with my server to get its network working now? Linux updates usually fix these things, not cause them. At this point I'm less suspicious that it's something wrong with Unraid or the NAS itself, but I'll continue to look into what's making this docker container act squirrely. Maybe it could be the downloader utility itself...

I have just found an error in the Fix Common Problems plugin; Realtek R8168 NIC found The default Realtek NIC driver is known to have issues, consider installing the driver plugin from Community Applications if you are having stability issues or trouble with networking. Search for: r8168 in Community Applications, install the plugin and reboot your server. This sounds about right, considering the problems I've been having. Though it's very strange, I built this server in late 2020 and have never had networking issues with it until some time in 2022/2023. But I'm getting ready for bed now, so I'll have to come back and look at this avenue later. In the meantime, if anyone thinks of anything else, feel free to post, just in case.

Lately I've noticed that my Unraid machine has been really slow when performing certain actions, but not others. File transfers to/from the NAS and browsing directories over the network are fine from what I can tell, but the problem is when the NAS itself needs to access the internet. I first noticed it a few OS updates ago, Docker container updates would go exceptionally slow. I thought it might just be Unraid's docker implementation doing things and not being very verbose, or perhaps Docker's CDN itself. It specifically seems to be hanging on attempting to find things on the internet; Docker updates will hang at "Please wait...." for a long time, and then "pulling fs layer" hangs on multiple lines, but once the actual download for each layer starts, the download usually goes at an acceptable speed. If updating docker containers, the whole webGUI seems to freeze while it is trying to start fetching a file (please wait, fetching fs layer). Once the download of that file starts, the webGUI unfreezes until it attempts to fetch another remote file. Checking for, and updating plugins also seems to take a very long time. I occasionally remote into the NAS and use wget to place files I want into a directory, and I do see the occasional slow download speed, but I'd pin that on the remote servers. Lately I've been experimenting with archiving utilities like youtube-dl, PixivUtil2, and others. I was experimenting with GinNoKami's docker container when I saw PixivUtil2 was erroring out with (<class 'urllib.error.URLError'>, URLError(gaierror(-2, 'Name does not resolve') It would do this intermittently, when I tried to download images/posts, some images would error out while others were fine, and while having the utility browse through users' bookmark pages (to download their bookmarks), PixivUtil2 was getting the error while trying to fetch the webpages (PixivUtil2 seems to walk the pages of a user's bookmarks in order to get a list of images to get). Other machines on my network are fine. I have a desktop physically sitting next to the NAS, plugged into the same router, with the same path to the internet, and it doesn't have the same problems the NAS has when accessing things on the internet. I even did a few runs of PixivUtil2 from the desktop machine and it worked fine for everything I tested. YoutubeDL also works fine from the desktop, but I haven't tested it from the NAS yet. Considering the NAS also seems to be having issues while checking for/downloading its own stuff, I'm pretty sure something's acting up with the NAS itself, and not the applications. I don't think this type of stuff is likely to show up meaningfully in (unraid's) logs, how can I troubleshoot this?

At some point between my first discovery and installation of the TubeArchivist docker, custom Redis and ES container requirements have been added. I have installed them and fixed the built-in bug for the TubeArchivist-ES container (some sort of java or permissions error, had to chmod 777 the /mnt/user/appdata/TubeArchivist/es directory for some reason in order to get it to work). However, because I've had to create a new Elasticsearch database, all of the videos I had previously downloaded are no longer detected by TubeArchivist, and TA thinks I have no videos. Copying the old ES database into the folder for the new ES container, and using (what I believe to be) the old password, TA crashes. It seems the old ES database is missing the path.repo variable (I'm guessing) and I don't know if I can add it to the old database. TA seems to just be refusing the original database now, even if I spin up the old ES container that I used a year ago (including if I add the same path.repo variable from the TA-ES container). Isn't there a way to just... Scan the files on disk and add the data that has already been archived to the new database? Or migrate the data from the old ES to the new TubeArchivist-ES? Edit, after looking through TA's settings again, I found where the settings I was looking for were; Rescanning the filesystem to add orphaned files failed because at some point redis created a dump.rdb file in the top level of TA's /youtube. I removed it, and maybe the rescan would have worked now, but I also found that TA thankfully (?) found a backup of my previous (original) ES database. Apparently, importing the old ES database backup worked, and my videos all seem to be back now, but I get the feeling that the TA-ES and main TA containers were very unhappy with the import. I sure hope importing the old "clearly inferior" database doesn't come back to bite me...

I asked in the linuxserver Discord; diskover v2 isn't released yet. It seems to currently be in a sort of closed beta.

It appears that this repo has been abandoned in favor of the new diskover v2. This seems to have happened in just the last few days. In the mean time, it looks like this docker image is now broken? rq-dashboard is unable to start.

Currently I have my main rig as my "full node" and will be creating pooled plots on it and transferring them to unassigned devices on the server. I've heard the Chia network doesn't like multiple full nodes under the same internet IP address, so when all of the plots are finished, I want to install the docker container and have the server acting as the "full node" and able to farm to a pool on its own (and plot if necessary). Ideally I want to be able to check the balance using the wallet from my main PC (or possibly other PCs) with the server being the "master node" on the network. Can we also configure where the docker stores the Chia blockchain when running a full node? I don't want it eating up all the space on my cache drive after a few years, so I want to store the blockchain somewhere on the unraid array.

Thank you @ich777 for your work on docker servers so far. If you're feeling up to the task, there is a game called Space Engineers that's been out for quite a few years now. As it stands, it is a Windows-only game with its own Windows-only server software that runs through steamCMD. Many have tried, and as of this post, I believe there are a couple of working dockers out there for the base SE server. However, SE is a game like Minecraft; there exists a custom style of server called Torch, which has been challenged by many in getting a working Docker container up and running. Running a non-Torch SE server is like running Skyrim or Minecraft without mods (even OptiFine). Torch has a plugins system with numerous quality of life and functionality-improving features. There have been a few functional Torch-based dockers in the past, and about a year ago I tried all of them to no success - they had all broken with time. If you could get a linux or unraid-friendly docker for SE working, especially a Torch server, I know it would be greatly appreciated by a community of players. Both SE and the Torch guys have their own Discord servers with linux-specific sections that probably have lots of people eager to help.