-
[SUPPORT] pihole for unRaid - Spants repo
Here's my config (with a few things redacted, and IPv6 stuff removed / disabled to make it a bit simpler). I've had it running for quite a while now, so it's far from a fresh install. If you haven't already, I'd recommend reading the config guide on Docker Hub: https://hub.docker.com/r/pihole/pihole Particularly the Important Upgrade Notes and Environment Variables sections, as they explain in more detail the various "DNS" entries. Repository: pihole/pihole:latest Docker Hub URL: https://hub.docker.com/r/pihole/pihole Icon URL: https://i.imgur.com/OWkNcEn.png WebUI: http://[IP]:[PORT:80]/admin Extra Parameters: --cap-add=NET_ADMIN --dns 127.0.0.1 --dns 1.1.1.1 Network Type: 'Custom: br0' Fixed IP address (optional): 10.1.1.100 Privileged: Off Variables ('Key'='Value') 'ServerIP'='10.1.1.100' 'WEBPASSWORD'='my password' 'DNS1'='1.1.1.1' 'DNS2'='1.0.0.1' 'IPv6'='False' 'INTERFACE'='eth0' 'DNSMASQ_LISTENING'='all' Ports (host port : connection type) 53 : TCP 53 : UDP 80 : TCP Paths ('container path' : 'host path' : 'access mode') '/etc/pihole/' : '/mnt/cache/appdata/pihole/pihole/' : 'Read/Write' '/etc/dnsmasq.d/': '/mnt/cache/appdata/pihole/dnsmasq.d/' : 'Read/Write'
-
[Support] Linuxserver.io - Plex Media Server
Might be worth trying to change the “LAN Networks” setting in Plex under Network (enable advanced settings). They’re entered in the format: 127.0.0.1,192.168.1.0/255.255.255.0 More details here: https://support.plex.tv/articles/200430283-network/
-
[SUPPORT] pihole for unRaid - Spants repo
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
-
[Support] Linuxserver.io - Plex Media Server
Try mapping the /config path to a cache or disk share, rather than the user share. Will depend on where your “appdata” is stored, e.g. /mnt/cache/appdata/plex or /mnt/disk1/appdata/plex See this post for some details why:
-
[SUPPORT] pihole for unRaid - Spants repo
I had the same issue with nothing in the Query Log or data in the graphs. diginc posted a fix in an issue raised for this on GitHub, and it worked for me. Although the only step I had to do was edit the config file /dnsmasq.d/01-pihole.conf and change the line from "log-queries" to "log-queries=extra", then restart the container.
-
Tyler started following Dynamix File Integrity plugin , [Support] Linuxserver.io - Tautulli , [Support] Linuxserver.io - Plex Media Server and 4 others
-
[Support] Linuxserver.io - Plex Media Server
Have a look at this help article: https://support.plex.tv/hc/en-us/articles/201370363-Move-an-Install-to-Another-System I’ve used this method successfully to move my library around in the past. The first step to disable the emptying of trash is important, but sounds like this may already be too late unless you’ve got a backup of the appdata from your Win10 system.
-
[Support] Linuxserver.io - SmokePing
Thanks @CHBMB and @sparklyballs! Now working for me with the fping IPV4 only build. You've gone above and beyond to get this working with v6.3
-
[Support] Linuxserver.io - SmokePing
Thanks for the replies guys. Yes and with multiple browsers (Firefox, Safari, Chrome), still nothing on the graphs. Me too, only using IPV4. Running unRAID 6.3.5
-
[Support] Linuxserver.io - SmokePing
Thanks. I should have checked the scripts to make sure I was running the correct command. When running this with the --debug option I still see the same error with fping. FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Also tried running the same fping command directly and also same result. Can someone who has everything working try running fping to see if they get this same error? root@c381ec688e22:/$ s6-setuidgid abc /usr/bin/smokeping --config="/etc/smokeping/config" --nodaemon --debug ### assuming you are using an fping copy reporting in milliseconds ### Compiling alert detector pattern 'someloss' ### >0%,*12*,>0%,*12*,>0% my $d = shift; sub { my $y = $d->{loss}; for(1){ my $imax2 = min(@$y - 3, 12); my $imax1 = min(@$y - 3, 12); my $minlength = 3; my $maxlength = 27; next if scalar @$y < $minlength ; my $i1; for($i1=0; $i1 < min($maxlength,$imax1); $i1++){ my $i2; for($i2=0; $i2 < min($maxlength-$i1,$imax2); $i2++){ next unless defined $y->[-3-$i1-$i2] and $y->[-3-$i1-$i2] =~ /^\d/ and $y->[-3-$i1-$i2] > 0 ; last; } return 0 if $i2 >= min($maxlength-$i1-$i2,$imax2); next unless defined $y->[-2-$i1] and $y->[-2-$i1] =~ /^\d/ and $y->[-2-$i1] > 0 ; last; } return 0 if $i1 >= min($maxlength-$i1,$imax1); next unless defined $y->[-1] and $y->[-1] =~ /^\d/ and $y->[-1] > 0 ; return 1; } return 0; } Smokeping version 2.006011 successfully launched. Not entering multiprocess mode with '--debug'. Use '--debug-daemon' for that. FPing: probing 20 targets with step 300 s and offset 294 s. FPing: Executing /usr/sbin/fping -C 20 -q -B1 -r1 -i10 cam.ac.uk facebook.com web.mit.edu linuxserver.io 208.67.220.220 al.ktz.me www.ucsd.edu 208.67.222.222 www.berkley.edu 8.8.4.4 google.com www.telefonica.de jupiterbroadcasting.com youtube.com www.indiana.edu www.uea.ac.uk 8.8.8.8 cixp.web.cern.ch FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Calling RRDs::update(/data/DNS/OpenDNS2.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/GoogleDNS2.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/OpenDNS1.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/GoogleDNS1.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/UEA.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/CambridgeUni.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/IBNorwich.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Germany/TelefonicaDE.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Switzerland/CernIXP.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Switzerland/SBB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/JupiterBroadcasting.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/GoogleSearch.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/Facebook.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/Youtube.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/linuxserverio.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/MIT.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCSD.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/IU.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/Sun.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) root@c381ec688e22:/$ s6-setuidgid abc /usr/sbin/fping -C 20 -q -B1 -r1 -i10 cam.ac.uk facebook.com web.mit.edu linuxserver.io 208.67.220.220 al.ktz.me www.ucsd.edu 208.67.222.222 www.berkley.edu 8.8.4.4 google.com www.telefonica.de jupiterbroadcasting.com youtube.com www.indiana.edu www.uea.ac.uk 8.8.8.8 cixp.web.cern.ch (null): can't create raw socket (must run as root?) : Address family not supported by protocol
-
[Support] Linuxserver.io - SmokePing
Hi all, I'm trying to use this docker app too, but can't seem to get it working. I use a bunch of other Linuxserver.io containers without any issues (thanks guys!). Here's my docker run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="smokeping" --net="bridge" -e TZ="Australia/Sydney" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8050:80/tcp -v "/mnt/cache/appdata/smokeping/data":"/data":rw -v "/mnt/cache/appdata/smokeping/config":"/config":rw linuxserver/smokeping In my unRAID network config I have bonding and bridging both disabled, I tried enabling bridging without any difference. I've tried to do some troubleshooting and I think @ziggie216 was onto something with this. How I arrived at this was checking the in-built Smokeping troubleshooting from within the Smokeping docker's shell. There does seems to be an inconsequential issue with the basic Smokeping troubleshooting saying the config file can't be found. But the config is definitely being picked-up because I can see all the (empty) graphs for each of the targets configured by the docker container. root@212bb2c07243:/$ smokeping --check ERROR: can't open /usr/bin/../etc/smokeping/config: No such file or directory root@212bb2c07243:/$ smokeping --debug ERROR: loading smokeping configuration file /usr/bin/../etc/smokeping/config: No such file or directory Running the Smokeping debug command against the actual config file gives this result: root@212bb2c07243:/$ smokeping --config /etc/smokeping/config --debug ### assuming you are using an fping copy reporting in milliseconds ### Compiling alert detector pattern 'someloss' ### >0%,*12*,>0%,*12*,>0% sub { my $d = shift; my $y = $d->{loss}; for(1){ my $imax2 = min(@$y - 3, 12); my $imax1 = min(@$y - 3, 12); my $minlength = 3; my $maxlength = 27; next if scalar @$y < $minlength ; my $i1; for($i1=0; $i1 < min($maxlength,$imax1); $i1++){ my $i2; for($i2=0; $i2 < min($maxlength-$i1,$imax2); $i2++){ next unless defined $y->[-3-$i1-$i2] and $y->[-3-$i1-$i2] =~ /^\d/ and $y->[-3-$i1-$i2] > 0 ; last; } return 0 if $i2 >= min($maxlength-$i1-$i2,$imax2); next unless defined $y->[-2-$i1] and $y->[-2-$i1] =~ /^\d/ and $y->[-2-$i1] > 0 ; last; } return 0 if $i1 >= min($maxlength-$i1,$imax1); next unless defined $y->[-1] and $y->[-1] =~ /^\d/ and $y->[-1] > 0 ; return 1; } return 0; } Smokeping version 2.006011 successfully launched. Not entering multiprocess mode with '--debug'. Use '--debug-daemon' for that. FPing: probing 20 targets with step 300 s and offset 212 s. FPing: Executing /usr/sbin/fping -C 20 -q -B1 -r1 -i10 www.uea.ac.uk www.ucsd.edu 208.67.220.220 8.8.4.4 google.com web.mit.edu youtube.com 8.8.8.8 www.telefonica.de www.indiana.edu www.berkley.edu 208.67.222.222 jupiterbroadcasting.com al.ktz.me cam.ac.uk facebook.com linuxserver.io cixp.web.cern.ch FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Calling RRDs::update(/data/USA/IU.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCSD.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) ... continues for each target (site/IP) ... If I try to run "fping" from within the docker's shell I get: root@212bb2c07243:/$ /usr/sbin/fping 8.8.8.8 (null): can't create raw socket (must run as root?) : Address family not supported by protocol So from what I can see "fping" doesn't run due to come sort of permission error, and possibly why no data is getting into the Smokeping RRD files / graphs. Searching for a solution only really turns up results relating to user/file permissions of "fping". So I tried messing with various file permissions and ownership with no result. Does anyone have any ideas or suggestions? Thanks!
-
[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)
No problem, glad it helped. Just a suggestion for the Home Assistant config, you probably want to enable the configuration option for "use_x_forwarded_for" so the client's IP address is passed to Home Assistant rather than the IP of the Nginx docker. This also allows you to use the IP Ban options. More details on the Home Assistant HTTP config page: https://home-assistant.io/components/http/ Here's a sample config for Home Assistant: http: api_password: MyPassWord base_url: SUB.MYDOMAIN.com:8123 use_x_forwarded_for: True ip_ban_enabled: True login_attempts_threshold: 5 And on the Nginx config side you've already got the relevant Proxy setting enabled: server { ... location / { ... proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ... } } That being said, if you're security conscious you're likely far better off managing things at the Nginx layer. And it's great that this docker already has Fail2ban built in.
-
[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)
Hi ritalin I have this Letsencrypt / Nginx docker, and the Home Assistant docker setup working. Just wanted to check if you've had a read of the Home Assistant team's guide for setting up Nginx: https://home-assistant.io/ecosystem/nginx/ Specifically their sample config in step 8 (looks like you've already done the rest). This is what I based my config on, and having a quick look over your config it seems to be missing a few settings/parameters. I'm by no means an expert with Nginx or docker, but if you're still having issues I can post a copy of my configs.
-
[Support] Linuxserver.io - Plex Media Server
The updated Plex container is working well for me. Grabbing the current Plex Pass version (0.9.16.4) using "VERSION=latest". Thanks lonix and to all the Linuxserver.io team for your great work!
-
The 5X3 Cage review - Norco, SuperMicro, iStarUSA and Icy Dock
I've swapped the the stock fans in my Norco SS-500 for non-PWM Noctua NF-R8 fans. I run them at full speed, so don't use the included fan speed controllers. Take a look at this review, gives a really good run-down of the cages and the process for swapping the fan. http://greenleaf-technology.com/new-norco-ss-500-5-in-3-drive-cage-review/
-
Preclear.sh results - Questions about your results? Post them here.
Thanks for the reply. That makes sense. I probably should have read up on what the script actually does in detail. Just to give things more of a test, I ran a 2nd preclear on the same 1TB WD Black disk, and it went significantly faster the 2nd time: 11:43 vs 24:16 The only thing I did between the 2 runs was power down the box for about an hour to re-route some cabling and install a few new fans. I've now precleared a total of 5 disks, and this was the only run that was slow. Fingers crossed this was just one of those weird occurrences.
Tyler
Members
-
Joined
-
Last visited