mbezzo

Anyone figure this out? Definitely interested...

I just edited the docker and changed the docker path from the old one to the new one: linuxserver/hydra2 to linuxserver/nzbhydra2 Then just save it, and it'll update the stuffs and be all set - don't need to copy/move/config anything! Don't forget to go to advanced mode and edit the Docker Hub URL too! (from experience, ahem)

yeah, I'm aware of the massive Nest changes - but none of them have hit yet. That's all happening later this year (and now they've sort of rescinded and are saying existing API use will not be disabled - you just can't make any new ones) So... that doesn't quite explain it. Curious if anyone else using this docker still has Nest working?

And while I'm at it, has anybody figured out how to configure the Homebridge docker to see the log from the Homebridge gui?

I've narrowed it down to the Nest plugin. No changes whatsoever related to my Nest config - anybody have any ideas? I've completely removed the docker/nuked its appdata folder and completely rebuilt. Same issue - if I remove nest it works great. WTF! lol I've even issued a new api token! Anybody hear of any issues with Nest? I can't seem to find much... thanks all!

these are the 3 errors. the one from my OP just reads as text (not colored). thanks!

is this what you're looking for? the error would be the last line - takes awhile to show up so it's not in this one. thanks! homebridge.log

I'm getting this after updating homebridge: terminate called after throwing an instance of 'std::bad_alloc' Any ideas? Thanks!

Thanks, @peteknot - shoulda looked there first! Yup - just deleted/re-added (copied all my settings and re-entered them) and all is well. Thanks again!

Hey all, just updated this evening to the latest release, and I'm getting this in my logs. Any ideas? ::: Starting docker specific setup for docker pihole/pihole WARNING Misconfigured DNS in /etc/resolv.conf: Two DNS servers are recommended, 127.0.0.1 and any backup server WARNING Misconfigured DNS in /etc/resolv.conf: Primary DNS should be 127.0.0.1 (found 127.0.0.11) nameserver 127.0.0.11 It quickly just fails and stops after this error. Didn't have any issues with it prior to the update (and no config changes either).

Hi All, I've been trying to get the mastodon dockerhub docker running, but no luck. Anyone willing to unRAIDify this one? https://hub.docker.com/r/tootsuite/mastodon/ https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Docker-Guide.md Much appreciated! Matt

FWIW, I'd be interested in this too!

THANKS @Tyler! This did the trick for me. I can't quite remember if I changed that to br0 or not - seems like that was default... Appreciate the reply!

Thanks! And yes, the more the merrier to get this issue resolved

Submitted this if others with the issue want to add on/comment: https://github.com/pi-hole/docker-pi-hole/issues/321

Thanks, @spants - will do!

Glad to hear I'm not alone - I was really pulling my hair out on this one!

V4.0 works great for me for awhile, then it completely stops resolving DNS. I think it seems to be after the first reboot. Anybody else figure out how to fix this? If I nuke it all and reinstall - samething. Works great for awhile, then no DNS resolution...

Thanks, John - that's exactly the info I was looking for. The issue definitely seems to be much better in my case, but I've seen it several times over the past 1.5 months. It always recovers and usually never last for more than 10 mins. I'm going to try moving things to /mnt/cache and see how it goes. Thanks again!

ah, okay that might make more sense then. I was thinking that since I do have a cache drive, and appdata is set to cache only, that even though my paths are /mnt/user/appdata - it still is on the cache drive. aWhich is exactly why I didn't understand Squids suggestion. Hopefully that makes sense! That being said, since mine are already on the cache drive - changing to /mnt/cache won't do much or me, will it? Thanks!

@SquidI know this is a really old post, but I'm super curious as to why you say to move /config from /mnt/user to /mnt/cache/? What changes when we do this? I'm new to unRaid and trying to figure it all out still. Secondarily, (and this isn't directed at you!) if we should point there, why does unRaid point to /mnt/user by default? I'm still randomly seeing this shfs process go nuts. It's pretty random for me, but definitely happens every few days. If I just leave it alone, it seems to recover so not a huge deal... but all my dockers freeze up when this happens, so have been searching for solutions and came across this. Thanks!

Thanks! I've switched the container to /mnt/user/downloadsfolder and all is well while mover is running. Appreciate the help and pointers!

I'm new (Very) to unRAID and just had a thought. If cached is off for the downloadsshare, but I point the container to /mnt/cache/downloadsfolder - that would still be writing to the cached SSD's, right? I think this concept is what's confusing me... If I had caching ON and pointed to /mnt/user/downloadsfolder - that'd be effectively the same as caching off, but then pointing to /mnt/cache/downloadsfolder? Appreciate the help!

It is set to yes - should I turn that off? in my testing I seem to get way better downloads/processing speeds with it on.

Hi All, Wondering if anybody else is seeing this/has any suggestions: Basically, NZBget is working perfectly, happily downloading and process files UNTIL mover starts. As soon as mover starts, it throws error after error like this: [ERROR] Could not create file /downloads/tmp/nzb-24.tmp As soon as mover stops, the errors stop and all is well. I can't restart or do anything with the container during the mover operation. I've got it mapped like this: /downloads /mnt/cache/downloadsfolder /config /mnt/user/appdata/nzbget Any ideas? thank you!