hammsandwich

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

2 Neutral

About hammsandwich

  • Rank
    Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Has anyone had luck with PCI passthrough and IOMMU groups on these new BIOS's? I head there were issues. I have a Win10 VM with multiple PCI passthrough devices, including NVMe, NVIDIA GPU, and onboard USB controller (with ACS patch).
  2. As this docker relies on an older version of the upstream lancache dockers, and he is not tagging the builds or pulling tagged versions, I do not think this is currently possible.
  3. Looks like a new version was built off a fork to remove snip proxy. Any pull this yet and see if it works? I am not in front of a computer to test.
  4. Same here after latest update. Same error messages filling up nginx error logs.
  5. I bought 2x SAMSUNG M391A2K43BB1-CTD 16GB from Server Supply. I am still dialing the timings an trying to keep voltage under 1.35v since its running 24/7. The nice thing about OC'ing ECC RAM is it gives you plenty of warnings (single-bit recoverable errors) that its not fully stable.
  6. I have a Ryzen 2700X on an Asrock x470 with 32GB ECC. The Asrock handles the ECC wonderfully, and I was even able to OC it to a respectable 3133 MHz(I am a little crazy). I use it as a media server and Win 10 gaming VM with a 2070 Super passed through to a Win 10 VM. I also have it configured to dual boot to Win 10 (see aforementioned note on crazy), and honestly playing demanding titles like BFV, its hard to notice the difference in performance between VM and bare metal. I can really only measure a difference if I run benchmarks like Fire Strike or Cinebench. I give Unraid 2C/4T on the f
  7. I am facing an issue were I am whenever access the "Main" or "Dashboard" parts of the UI, the Unraid log is filled with something similar to below. "authlimit", client: 10.0.199.86, server: , request: "GET /webGui/images/css.png HTTP/2.0", host: "192.168.100.99", referrer: "https://192.168.100.99/Main" Oct 2 10:07:45 unraid nginx: 2019/10/02 10:07:45 [error] 7944#7944: *2037286 limiting requests, excess: 20.997 by zone "authlimit", client: 10.0.199.86, server: , request: "GET /webGui/images/ui-icons_888888_256x240.png HTTP/2.0", host: "192.168.100.99", referrer: "https://192.168.100
  8. I too am having this same issue. I have noticed actually my Unraid server idles at LOWER watts (10-15 watts lower) when the Windows VM with GPU pass-through is booted than when that VM is shutdown or sleeped. I might build a 1 CPU 2 GB VM to run and pass-through the GPU to while I am not using it. I have a RTX 2070 Super, and upgraded from a AMD RX 480 which I did not notice this issue.
  9. So I have narrowed this down to being an issue with Unraid VMs accessing any binhex containers on the same Unraid host. From a separate client (i.e.laptop), everything works perfectly fine. I can access rutorrent UI, Privoxy, all working perfectly. From a VM on Unraid, I can access all my container UIs (netdata, radarr & sonarr [linuxserver]), but Privoxy and rutorrent UI remain inaccessible. Any ideas?
  10. Hi. Thanks for all the hard work for this and all your other containers. I am having issues with getting Privoxy to function in any of your containers. I am running 6.7.0-rc5. When I run your rtorrent container, with privoxy flag set to yes, rtorrent works, vpn works, I can DL and UP torrents just fine. However, I cannot access the Privoxy port. Just firing this container up on its own results in the same behavior. When I set the proxy address in my browser all internet access dies until I remove it. Using Wireshark I see TCP Retransmission like the container is not listening on the port
  11. I am having an issue with the latest 2 builds, 0.9.7-1-08 and 0.9.7.-1-09. I have been running and updating this container on a Synology with PIA for some time now without issue (disabling apparmor still). Last week I updated to the latest version -08 at the time, and my logs indicate a DNS issue. Today I saw a new version was release, and updated to -09, and the problem persists. 0.9.7-1-07 appears to be working properly at this time. See errors below. 2018-08-15 18:44:56,578 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2018-
  12. I was the initial person on this forum to point out the issue the this container on Synology and the AppArmor issues. I am also the same person who posted that on Reddit. I have opened a trouble ticket, as well as put in a feature request and posted on the Synology forums (https://forum.synology.com/enu/viewtopic.php?f=3&t=118103). Unfortunately, I still have not found a resolution other than disabling AppArmor. Another interesting issue I have run into is Docker refuses to start other other containers after I disable AppArmor. I have a startup script that runs o
  13. This looks a lot like the permissions issue I was getting due to apparmor and the symlink to the nginx config.
  14. what are you changing in the rtorrent.rc file?, it should be simply changing to the values below:- # Enable DHT support for trackerless torrents or when all trackers are down. # May be set to "disable" (completely disable DHT), "off" (do not start DHT), # "auto" (start and stop DHT as needed), or "on" (start DHT immediately). # The default is "off". For DHT to work, a session directory must be defined. # dht = off # Enable peer exchange (for torrents not marked private) # peer_exchange = no keep in mind if your editing using windows notepad then you could be screwing up the l