Phastor

Update: I gave in and canceled the job by hitting "Fix Preclear," which apparently is supposed to clear all preclear jobs out of the queue. Upon starting the job again, it said that the disk already had a preclear job started and picked right back up where it left off. Wish I did that sooner. Could have saved about 24 hours of it sitting there and doing nothing, but I was afraid hitting that button and resuming would have killed the job, if it wasn't dead already.

unRAID Version: 6.12.10 Plugin Verision: 2025.02.14 I started a preclear of a 16TB disk the other day using the Unassigned Devices Preclear plugin. It got through its first read pass late last evening and started on its zero pass. After waking up this morning, I see that it has stopped after about nine hours into the zeroing pass. There are no errors, and the job still appears under my main dashboard as well as within the preclear plugin. Not the progress percentage nor elapsed time is updating anymore. It is stuck at 49% and 9 hours. It gave no errors. It just stopped. There is also no activity light from the disk at all now. I initially thought it might have been my nightly AppData backup stopping plugins and containers (including the preclear plugin), but it ran overnight during the read pass the previous night and it didn't stop then. The last line in the preclear log shows the following: Mar 05 03:40:18 preclear_disk_<serial>_21666: SIGEXIT received, exiting ... I have tried to "Resume all sessions" from within the preclear plugin settings, but it did nothing. Is there a way I can resume this without having to start over? If I do have to start over, any idea what might have caused this so I can prevent it from happening again?

I just did a big jump in updating my server last night going from 6.7.x to 6.12.10. I noticed that my server has also gone unresponsive similar to how OP has. I'm not sure if it's just network related or something deeper. I have a monitor plugged into the server now so I can see if it's still running after I lose access to it again over the network. I noticed that Fix Common Problems is giving me a "MACVLAN and bridging found" warning" and wonder if if this could be the culprit (provided that the issue is only network related). How would switching this to IPVLAN affect any docker containers I have set up on custom networks? I've got a proxy network set up with Swag and some other containers that I use for outside access.

A few years ago I followed SpaceInvaderOne's guide on bundling up some containers with Let'sEncrypt on a proxy network. I put things that I need access to the outside to on this network such as my HomeAssistant instance, Plex, etc. I just installed the Matter-Server container, which it requires to be on the host network. Makes sense since it has to talk to the matter devices on my network. However, I've run into an issue since that container also has to be able to communicate with my HomeAssistant container, which is on the proxy docker network. What are my options?

Just gave this a shot. Unfortunately it's a no go for me. Glad you got yours fixed though!

Nope. Still no luck. Was told by someone else here I should check in with the Sonarr forums about trying to recover the database, but at this point I'm wondering if it would more efficient to just blow away all my appdata and start over. I really don't want to do that though. That's a lot of profiles and settings I do not want to have to create again.

Just a connection refused error as if nothing is listening on that port Here's a segment that stands out to me from the logs. "2024-03-27 10:25:32,605 DEBG 'sonarr' stdout output: [Fatal] ConsoleApp: EPIC FAIL! [v4.0.2.1183] NzbDrone.Common.Exceptions.SonarrStartupException: Sonarr failed to start: Error creating main database ---> System.Text.Json.JsonException: '|' is invalid after a value. Expected either ',', '}', or ']'. Path: $ | LineNumber: 33 | BytePositionInLine: 0. ---> System.Text.Json.JsonReaderException: '|' is invalid after a value. Expected either ',', '}', or ']'. LineNumber: 33 | BytePositionInLine: 0. at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes) at System.Text.Json.Utf8JsonReader.ConsumeNextToken(Byte marker) at System.Text.Json.Utf8JsonReader.ConsumeNextTokenOrRollback(Byte marker) at System.Text.Json.Utf8JsonReader.ReadSingleSegment()" So I guess it is failing to start when using binhex/arch-sonarr

In the same fashion that I've accessed it before the issue. Currently, when accessing the UI when on binhex/arch-sonarr:v3, I can access the UI via the docker dashboard, or by accessing it directly via my unRAID server's IP and the container port number. When attempting to access the UI when on binhex/arch-sonarr, the UI is inaccessible via both of those methods.

Just gave this a shot and unfortunately that's still a no-go. No change in bahavior. Thanks though!

An update on this. I tried binhex\arch-sonarr:v3. The container UI is functional with this. I am still getting the "BlacklistSpecification: SQL logic error no such table: Blacklist" error for every show episode though, so nothing monitored is being downloaded. Going back to binhex\arch-sonarr still makes the UI inaccessible.

So, I've ran into an issue that has been three years in the making. I have been using SABNZBD and the -arr suite for some time. I started out using the Binhex containers. Sometime in 2021, I switched the repository for my existing container from the Binhex source to Linuxserver's. I'm not exactly sure why I did this, but it might have been because of the major version release around that time and Linuxserver had a preview build of it. I only did this switch with Sonarr. Fast forward to a couple weeks ago, I noticed that the container was no longer updating and probably hasn't for some time. This is when I noticed and remembered that the container was pointed to the Linuxserver repository preview build, even though I know it was originally the Binhex container. I pointed it back to the Binhex repo and updated to pull down the new container. After updating, the web UI was no longer available. I didn't have time to mess with it, so I switched it back to the Linuxserver repo, updated, and everything looked good. "This is a future me problem" I thought. Fast forward again to today, and future me noticed that nothing has downloaded for any of my monitored shows in the last two weeks. I did a search on one of the shows that are on my calendar and there were indeed episodes that matched the criteria in my profiles that should have downloaded. However, they were all rejecting with the error. "BlacklistSpecification: SQL logic error no such table: Blacklist." I get this with every single entry for every single show. I can still manually download them, however. I did some research and apparently this happens when you upgrade Sonarr and then roll back. It seems that when I switched back to the Binhex repo and Sonarr was able to update again, it also updated the database. (So I'm guessing Sonarr was working under the hood even if the UI was busted) And since I had to switch back to Linuxserver's, it can now no longer properly read the database since it is an older version. I tried switching back to the Binhex repo again today, but were met with the same results as two weeks ago. An inaccessible UI. Since my database is now unreadable by the previous version, it looks like my only option short of wiping my Sonarr appdata is to figure out how to get it working using the container from the Binhex repo again. Again, I think it's working under the hood. The web UI just appears to be borked. Any ideas on where to start on troubleshooting this?

I'm using "remote access to lan" as my peer connection type. I've got an active tunnel and can remotely ping virtual machines running on my unRAID server as well as physical devices on my LAN over the tunnel. I can also access docker containers over the tunnel that are using network type "bridged". However, I cannot ping or access my PiHole container, which is using the network type "custom:br0" and has its own IP on my physical LAN's subnet. I'm guessing this has something to do with the container's IP being bound to the server's physical interface, but my VMs are configured the same way and I can access them just fine.

Nah. I've only got two USB devices aside from the flash. I've got my UPS plugged into USB2 on the board and the drive in the PCIe adapter.

As much as that would hurt, I'll give USB2 a shot. The USB drive in question is my Duplicati backup target, which is already slow the way it is. I may just get myself a small NAS for my backups if that turns out to be the issue. It's just weird since this issue only surfaced a few months ago after about two years of unRAID/UD use. Thanks for the help! I'll keep you posted with what happens.

This has happened with two different USB drives. I guess I'll need to scrounge up a third one and see. Or perhaps it could be a controller? I'm using a PCIe USB3 controller since my board does not have it onboard. Is it UD's interaction with the failed device that's causing the server-wide issues?

After about an hour of the diag page appearing locked up, it gave me the zip file. aivas-diagnostics-20200113-2202.zip

Just tried running diagnostics and that seems to have hosed my UI. This thing will go at the drop of a hat as soon as UD starts to do this. Will have to wait till I'm home to do a hard reset before I can look into it further.

I'm having an issue where Unassigned Devices will stop responding randomly. The UD section in my Main tab just gives me an unending dancing unRAID logo, I can't browse my USB connected drive, and any docker containers with folders mapped to that drive become unresponsive. It will also cause all of my CPU cores to appear to be pegged out in the Dashboard. When it does this, I am unable to stop any docker containers or my array. I am unable to shut down my server cleanly and my only option is to do a hard reset. If I try to do anything with UD when it does this, it will hose my web UI completely and I can't access anything until the server is hard reset. Any docker containers that I have not touched and do not have any mapped folders to my UD drive will continue to function. I can also still RDP into my Win10 VM. However, anything to do with browsing the server UI is not possible. I thought I read about this being a known issue and that it was addressed in a recent update, but it has just happened to me again. I am at work right now and am afraid to touch anything on it in fear that the web UI will get hosed and I won't be able to do anything with it until I get home.

I cannot for the life of me get Calibre-Web to see ebook-convert. I pulled the binary from a Calibre install, tossed it into /config within the container, and pointed Calibre-Web to the path to it. It's still reporting as not installed. I consoled into the container to run "ebook-convert --version" to see if it was actually functional at all and it returned an error regarding missing modules. Does it require dependcies? Does Calibre as a whole have to be installed within the container?

MXToolbox is reporting that my server does not support TLS. My knowledge in this sort of thing is limited, but I think I have pinpointed the problem. After issuing the EHLO command myself, it returned the following. 250-PIPELINING 250-8BITMIME 250-SMTPUTF8 250-SIZE 25214400 250 STARTTLS That last line is what draws my attention. It's got a space instead of a dash. MXToolbox is expecting "250-STARTTLS" and I'm guessing that's why it's marking it as not supported since that's not in the response that it's getting. I imagine this is something more for the original developer of the software to deal with--just hoping that it makes its way up the chain from here.

I've had a pretty stable set of backups for about 8 months now. Aside from the incredibly slow restore process (browsing folders within the backup is painful!), I've been pretty happy with it. However, I really wanted some of the newer features, such as improved performance during restores, so I switched to the canary build. I was not expecting my backup config to get wiped when I did this. Going back to the stable container returned the configs after some tweaking. Is there a safe way I can move my configs over to the canary build?

I'm confused on which version of Duplicati the container is running. From what I understand, they have made a lot of improvements in performance a few months ago as far as browsing your backups goes, but I am still having terrible results that seem to go back and forth with each update of the container. On average, after hitting "restore files," it takes about 8-10 minutes to finally be presented with a directory structure I can browse. It then takes 2-3 minutes for it to think on every folder I drill down in that structure. On some updates it gets better, as in it only takes a couple minutes to present the directories and then about thirty seconds to drill down each folder. But then, like in the latest update, it's back to taking several minutes again. Throughout the course of this, the actual version of Duplicati in the container has not changed and is reporting that it is 2.0.3.3_beta_2018-04-02.

How far back is the version of Duplicati in the container? Looking under "About", I'm seeing that the version is one dating back to last August. Is this accurate? If so, what kind of time window are we looking at for the docker container to be on the version that was released today? There's been some huge performance improvements to the latest version that I have been waiting for months on--namely the speed at which you can browse directories within your backups. Currently I am getting backups, but I wouldn't be able to use them if I were to need them since it literally takes like 15 minutes to drill down each individual directory. Getting this update will give me some peace of mind. Using the "check for updates" function within Duplicati itself detects the newest version that was released today. Is it possible use the in-app update function, or would that break the container? Edit: It's occurred to me that hitting "download now" may not be a self updater, but instead take you to a download page to get an installer, which I know would be useless in this case. I haven't tried it yet in case it actually is a self updater and would break the container.

Gotcha. I thought it would recursively scatter all individual files. Thanks for the clarification!

Thanks! Here's a scenario I was thinking of. I currently have a share called movies. Under that is a folder for each movie where the movie itself, subs, posters, etc reside. I have split levels set to only split the top level directory. This way each movie would reside on the same disk as its subs and whatnot. I wouldn't want a movie and it's related files stretched across multiple disks. If I felt the need to scatter the movies folder, say after I've gathered it to one disk for whatever reason, I would want scatter to follow the split levels so again the individual moves would stay together with their respective files. Or am I misunderstanding how this works?