mbezzo

Members
  • Posts

    71
  • Joined

  • Last visited

Posts posted by mbezzo

  1. On 11/13/2019 at 8:21 AM, Warrentheo said:

    Yah, I also have been looking into going this direction, was looking at a Crosshair VIII board, just need to know the IOMMU groups...

    Hey, I've got that board (no wifi version) with a placeholder (3200G) CPU until I can track down a 3950x - only have Windows on it right now, but if you can tell me how to list the groups from Windows - happy to post em later!

  2. 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?

  3. 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!

  4. 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).

    • Upvote 1
  5. On 8/31/2018 at 5:38 PM, Tyler said:

    I noticed something that could be the cause of your issue, in the Docker run command you posted in your GitHub issue that you've set the variable: 'INTERFACE'='br0'

    I believe this variable needs to refer to the name of the container's internal interface which is 'eth0', rather than the name of UnRaid network interface the container is running on which in your case is 'br0'

     

    @bonienl posted instructions a few pages back on how to re-configure this

     

    If you haven't tried this already it might be worth giving this a shot

    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! 

  6. 3 minutes ago, John_M said:

     

    There is a subtle difference between /mnt/user/appdata and /mnt/cache/appdata even when the share is set to cache only. The former is handled by shfs while the latter isn't. Hence Squid's suggestion to bypass shfs. I thought this issue had been fixed in the meantime, though.

     

    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!

  7. 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!