upthetoon

Thanks for the quick update. Just to confirm, does this fix both the issues encountered with unraid 7.2.5 and qbit moving to 5.2.0 or just the latter?

Anyone else on PIA having problems with this starting up properly? I'm not sure if PIA have changed the format of the response to what servers have port forwarding enabled. I can see the server I was using seems to be in the list but the name doesn't match now; "[info] PIA endpoint 'uk-southampton.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:" 2026-04-02 09:47:51,923 DEBG 'start-script' stdout output: [info] singapore.pvt.site [info] south-africa.pvt.site [info] saudi-arabia.pvt.site [info] uk-southampton.pvt.site

thank you again, that did it

Thanks, up and running but I have the same image issue as you now too.

From the docker page

Theres a new version out and I forced an update but it crashes at startup now with lots of "springframework" errors Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskService' defined in URL [jar:nested:/app/app.jar/!BOOT-INF/classes/!/org/booklore/service/task/TaskService.class]: Unsatisfied dependency expressed through constructor parameter 3: Error creating bean with name 'bookdropPeriodicScanTask' defined in URL [jar:nested:/app/app.jar/!BOOT-INF/classes/!/org/booklore/task/tasks/BookdropPeriodicScanTask.class]: Unsatisfied dependency expressed through constructor parameter 0: Error creating bean with name 'bookdropMonitoringService': Invocation of init method failed

FYI - I don't know why but when I walked through the logs in more detail it looked like there was some issue with the "direct unpack" function and it looking for files that weren't there anymore. I've disabled direct unpack and it appears to be unpacking files reliably again.

Has anyone had any issues with unpacking not happening but the download marked as complete? I'm getting quite a few of these now, was working fine. The password is correct and this is from a big indexer, example below... Name****WEB-DL.DDP5.1.H.264-FLUX Added NZB2 hours ago Completed2 hours ago StatusCompleted Size627.7 MB Categorysonnar Password****bsuY1 Path/media/usenet/completed/tv/*****WEB-DL.DDP5.1.H.264-FLUX Source*****WEB-DL.DDP5.1.H.264-FLUX.nzb DownloadDownloaded in 6 seconds at an average of 96.9 MB/s Age: 4d Serverseurope.newsgroupdirect.com=271.0 MB, news.eweka.nl=356.6 MB Repair[*****WEB-DL.DDP5.1.H.264-FLUX] Quick Check OK Unpack[7wQ7175rMqIO76pR4Hdo8LSJf449Tgb6] Trying unrar with password "***bsuY1" [7wQ7175rMqIO76pR4Hdo8LSJf449Tgb6] Unpacked 0 files/folders in 0 seconds [7wQ7175rMqIO76pR4Hdo8LSJf449Tgb6] Trying unrar with password "***bsuY1" [7wQ7175rMqIO76pR4Hdo8LSJf449Tgb6] Unpacked 0 files/folders in 0 seconds

I quite fancy upgrading my server from a tower to a rack mount hot swappable beast but finding a good enclosure in the UK seems quite difficult. https://www.bargainhardware.co.uk/superm-cse-848x-x10qbi-24-lff-hs-configure-to-order?c_b=44953 I found the above site but I'd want to swap out the M/B. Not sure if thats a stupid idea?

Thanks, shrinking the array now.

Hi, it's just happened again. Same drive but I'd changed the power and data cables. I have space enough that I could shrink that drive from the array, worth a shot? ridcully-diagnostics-20220810-1908.zip

Thanks Jorge. I've re-seated the cables and it's rebuilding the drive now.

Hi, I've had a drive disabled, I can see it is showing 2048 errors in the main screen. This happened about 6 months ago (I believe it was the same drive) but the diagnostics didn't indicate a drive issue. I re-seated the cables and brought the drive back into the array and it has been fine since. Can someone please take a look and let me know what the diagnostics indicate might be the problem? Thank you. ridcully-diagnostics-20220731-1035.zip

Happy birthday Unraid. I just checked and it's been 10 years since I built my server. It's only just had its guts replaced this year. I love how solid Unraid is now.

This got lost in all the replies I think. Invalid port in redirect target. Only ports 80 and 443 are supported, not 444 error anyone?

Sorry to add to the list of people with probably obvious issues but I'm having trouble getting this working too. I've been using it through the RC's and have unraid set to port 444 to avoid the clash. It was working fine before the CA change. I've followed the instructions above (thank you) and set the HTTPVAL flag to true. I'm using port 81 for the docker and have port 80 fwd to 81 in my router. I'm getting this error which I can't see is happening for anyone else... Failed authorization procedure. <redacted>.duckdns.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://<redacted>.unraid.net:444/.well-known/acme-challenge/QaX0x01RBkOvVSiPIP5VlKlhGyQDYNZXTuanOrzQ-n0: Invalid port in redirect target. Only ports 80 and 443 are supported, not 444 Startup command; root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e TZ="Europe/London" -e HOST_OS="unRAID" -e "EMAIL"="<redacted>" -e "URL"="duckdns.org" -e "SUBDOMAINS"="<redacted>" -e "ONLY_SUBDOMAINS"="true" -e "DHLEVEL"="2048" -e "PUID"="99" -e "PGID"="100" -e "HTTPVAL"="true" -p 81:80/tcp -p 443:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt

I couldn't see an obvious way to turn off https in unraid. I changed the secure port number in unraid which I don't think is a long term solution but has done the trick for now!

Seeing the same issue on rc8q; Error response from daemon: driver failed programming external connectivity on endpoint letsencrypt (~): Error starting userland proxy: listen tcp 0.0.0.0:443: bind: address already in useError: failed to start containers: letsencrypt

Thanks, I'll do the long smart test and see if that brings up anything interesting.

That diagnostic tool is great. Thanks for offering to take a look. The new disk is WDC_WD40EZRZ-00WN9B0_WD-WCC4E7RXXNR1 - 4 TB (sdg). It's 32C. No, some of the other disks were spun down. I had a look at the troubleshooting section before and have tried setting off a long smart test from the terminal. Not 100% sure it is running. ridcully-diagnostics-20170806-1257.zip

Yeah, did a preclear on the disk which went fine. Something is up now though, I can't get smartdisk info, just says "Please wait... retrieving S.M.A.R.T. information!" . The disk is still mounted and I can copy files from it. The identity tab looks ok; SMART support: Available - device has SMART capability. SMART support: Enabled SMART overall-health: Passed Other disks are fine and a reboot hasn't fixed it.

Hi, I just got a new drive so thought it would be a good time to make the move to XFS. I followed the wiki and took my next largest drive out of the global share settings and set of a rsync using nohup. It'd been killed after copying about 500GB of the 3TB drive; rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(636) [sender=3.1.2] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(504) [generator=3.1.2] Any ideas what could have caused this to stop? Is using nohup likely to cause issues with all the output being written out?

this docker is currently using the 10.0 repository, so whatever you're seeing it seems it's not that, that seems to affect 10.1 versions. currently (as in literally right at this very moment, working on moving over to 10.1) OK, thanks!

Hi, What version of MariaDB is in this docker? I think I'm seeing this issue... https://mariadb.atlassian.net/browse/MDEV-9181 Which is fixed in 10.1.11 forward. If it isn't already could this be moved up versions please?