Pi-hole in doker network problem

    • @Nefertiti

      I have an idea, but I'm not sure of the Linux command to do this, what you need to do is to release the ip address in omv (on windows machine it's ipconfig /release from the command line)
      Then reset your static ip option on your router, shutdown and reboot the should assign that new static ip via the router, the following is from the manual.


      According to that it will assign the ip to the Pi, but the current one needs to be released, what I found is dhcpclient -v -r from the command line, but to that you'll have to have a keyboard and monitor so you can shutdown shutdown -r now this will shutdown and reboot the Pi smoothly, rather than pulling the plug.
      Raid is not a backup! Would you go skydiving without a parachute?
    • Mr.Grape wrote:

      No control in the Ethernet layer over the address where each end user could assign any IP address as static would be unacceptable
      That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

      Nefertiti wrote:

      I think omv-firstaid fixit and probably the name eth0 was wrong should have been eth1 to make sure I should not assigned it as dynamic at the router level?
      Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      Mr.Grape wrote:

      No control in the Ethernet layer over the address where each end user could assign any IP address as static would be unacceptable
      That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

      Nefertiti wrote:

      I think omv-firstaid fixit and probably the name eth0 was wrong should have been eth1 to make sure I should not assigned it as dynamic at the router level?
      Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.
      Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!
    • Mr.Grape wrote:

      geaves wrote:

      To assign a static IP address to something on your network it needs to be outside of the DHCP scope/range
      Hmmm Imho, no ... Or I misunderstand you. ;)
      Whether the address is static or dynamic does not depend on whether it is out of the dhcp pool.

      On the dhcp side, I can give any IP from the pool for a specific MAC address and this IP will be static even though it will be in the dhcp pool.
      In the strictest sense, you're right. One can reserve a DCHP address, permanently, and assign that address to a specific MAC address. Going further, my router allows assigning a hostname to the reserved IP/Mac address combination. (Which allows for a simple version of local DNS.) That same address does not have to be supplied by the DHCP server, to the client, either. Since it's reserved, the same IP address can be statically set on the host.

      On the other hand, hashing off-topic details doesn't always help in solving the problem as outlined in the thread.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Nefertiti wrote:

      Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!
      What's the address you have assigned to OMV, in network settings?
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • geaves wrote:

      Mr.Grape wrote:

      No control in the Ethernet layer over the address where each end user could assign any IP address as static would be unacceptable
      That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

      Nefertiti wrote:

      I think omv-firstaid fixit and probably the name eth0 was wrong should have been eth1 to make sure I should not assigned it as dynamic at the router level?
      Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.
      Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!
    • flmaxey wrote:


      Nefertiti wrote:

      Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!
      What's the address you have assigned to OMV, in network settings?
      I assigned 192.168.2.150 now i got an other question related to your excellent guide I finished the instalation without anymore error but not sure if it is working since not completely sure about the Ip address I picked in it
      Images
      • 2018-09-22_155054.jpg

        526.3 kB, 1,516×2,284, viewed 13 times
    • The address is fine so long as it's in your network and NOT the server's IP address. That appears to be the case. Your server is 192.168.2.150. Pi-hole is 192.168.2.155 so all should work.

      However, from a previous post, I noticed that your router's DHCP range runs from .2 to .200. You now have two IP addresses, in use, within that range. If possible, I would go into your router and reserve those addresses so your routers DHCP server won't assign them to another host.
      (Otherwise, it's not the best way to set it up; with your server (.150) and Pi-hole (.155) running 24x7, it's unlikely that your router would assign an address that's in active use.)
      ________________________________________________

      You can test Pi-hole a couple ways. You can set one of your network clients with a static DNS address of 192.168.155 and go surfing. If the client connects to web sites, it works.
      Check Pi-holes console 192.168.1.155/admin/ You should see activity in the Dashboard. (If total queries is more than 0, it's working.)
      Finally, change your router's DNS server, to Pi-hole's address. This include change the DNS address for all statically addressed clients.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • flmaxey wrote:

      The address is fine so long as it's in your network and NOT the server's IP address. That appears to be the case. Your server is 192.168.2.150. Pi-hole is 192.168.2.155 so all should work.

      However, from a previous post, I noticed that your router's DHCP range runs from .2 to .200. You now have two IP addresses, in use, within that range. If possible, I would go into your router and reserve those addresses so your routers DHCP server won't assign them to another host.
      (Otherwise, it's not the best way to set it up; with your server (.150) and Pi-hole (.155) running 24x7, it's unlikely that your router would assign an address that's in active use.)
      ________________________________________________

      You can test Pi-hole a couple ways. You can set one of your network clients with a static DNS address of 192.168.155 and go surfing. If the client connects to web sites, it works.
      Check Pi-holes console 192.168.1.155/admin/ You should see activity in the Dashboard. (If total queries is more than 0, it's working.)
      Finally, change your router's DNS server, to Pi-hole's address. This include change the DNS address for all statically addressed clients.
      I changed the dhcp pool from 192.168.2.2 to192.168.2.100 ,But I checked from a browser without add blocking and it is not working wondering If I can setup dns in the router as discourse.pi-hole.net/t/how-do…e-as-their-dns-server/245 with the ip 192.168.2.155 in dns server on the lan page of the router

      Also http://192.168.2.155/admin is not resolving and when I go to docker container modify just to check under Macvlan settings the IP address is empty other issue but maybe this is ok the bridge container pihole name naughty_joliot says dead
      Please how can I fix it ?
      Images
      • 2018-09-22_203328.jpg

        72.09 kB, 877×427, viewed 12 times
      • 2018-09-22_212407.jpg

        141.46 kB, 1,058×804, viewed 12 times
      • 2018-09-22_215309.jpg

        98.88 kB, 872×457, viewed 12 times

      The post was edited 1 time, last by Nefertiti ().

    • Nefertiti wrote:

      But I checked from a browser without add blocking and it is not working
      Yes, add Pi-Holes DNS ip address to your router and apply your changes, but for clients to get the new settings, for windows using Command Prompt you can do ipconfig /release followed by ipconfig /renew to check it's picking up it it up ipconfig /all, iPads etc you an do from Settings, again release and renew.

      Your MacVlan is set incorrectly, when you set this up under Create Network, the Subnet should be 192.168.2.0/24, Gateway 192.168.2.2, and the parent eth1.

      Then in the container, under Macvlan Settings>>>Select macvlan network would display workgroup (192.168.2.0/24) then in the Ip Address add 192.168.2.150
      Raid is not a backup! Would you go skydiving without a parachute?
    • Nefertiti wrote:

      I changed the dhcp pool from 192.168.2.2 to192.168.2.100, But I checked from a browser without add blocking and it is not working wondering If I can setup dns in the router as discourse.pi-hole.net/t/how-do…e-as-their-dns-server/245 with the ip 192.168.2.155 in dns server on the lan page of the router
      Also http://192.168.2.155/admin is not resolving and when I go to docker container modify just to check under Macvlan settings the IP address is empty other issue but maybe this is ok the bridge container pihole name naughty_joliot says dead
      Please how can I fix it ?
      Reducing your scope (from 2 - 200 to 2 - 100) was a good idea. That free's up the addresses you're using for the server (150) and pi-hole (155). However, @geaves is right about the details of your configuration.

      A network statement such as 192.168.2.150/24 is "technically" the same as 192.168.2.0/24 but I have no idea how the MacVlan driver or the Docker Plugin would interpret the first address. It's best to use 192.168.2.0/24.

      Another note, regarding the missing IP address for your server in the MacVlan section:
      From experience, I've found that trying to alter a MacVlan network configuration, after it has been saved the first time, didn't always "take" or "save". It's best to delete the MacVlan network and configure it again, with the correct entries.

      Since the Pi-Hole docker container's networking is based on the MacVlan driver, if MacVlan settings are changed, it would probably be best to configure a new container from scratch. So, the best bet would be to delete the MacVlan and the container, and start over using 192.168.2.0/24
      ___________________________________________________________________

      When the above is done, in the Docker plugin, your container's STATUS should be running. If it's running, the first test is going to 192.168.2.155/admin in a browser. If you can't get into the console, there's no point in going further.

      If you can get into the console, that's when you'd change your router according to your link above.

      If you have clients accessing your network using DHCP, it's easier to simply reboot them or, if they're devices (TV's), power them off and on so they'll pick up a new address in your reduced DHCP range, and the Pi-holes DNS address from your router.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • geaves wrote:

      Nefertiti wrote:

      But I checked from a browser without add blocking and it is not working
      Yes, add Pi-Holes DNS ip address to your router and apply your changes, but for clients to get the new settings, for windows using Command Prompt you can do ipconfig /release followed by ipconfig /renew to check it's picking up it it up ipconfig /all, iPads etc you an do from Settings, again release and renew.
      Your MacVlan is set incorrectly, when you set this up under Create Network, the Subnet should be 192.168.2.0/24, Gateway 192.168.2.2, and the parent eth1.

      Then in the container, under Macvlan Settings>>>Select macvlan network would display workgroup (192.168.2.0/24) then in the Ip Address add 192.168.2.150
      I think I got it it working in macvlan I used 192.168.2.0/24, Gateway 192.168.2.1 since it is my router , and the parent eth1. strangely pi_hole insit on eth0 in the login page
      I got confused about IP address of192.168.2.150 since it is OMV IP but I think I tried 192.168.2.155 and it was not working ( I was confused there)

      flmaxey wrote:


      Nefertiti wrote:

      I changed the dhcp pool from 192.168.2.2 to192.168.2.100, But I checked from a browser without add blocking and it is not working wondering If I can setup dns in the router as discourse.pi-hole.net/t/how-do…e-as-their-dns-server/245 with the ip 192.168.2.155 in dns server on the lan page of the router
      Also http://192.168.2.155/admin is not resolving and when I go to docker container modify just to check under Macvlan settings the IP address is empty other issue but maybe this is ok the bridge container pihole name naughty_joliot says dead
      Please how can I fix it ?
      Reducing your scope (from 2 - 200 to 2 - 100) was a good idea. That free's up the addresses you're using for the server (150) and pi-hole (155). However, @geaves is right about the details of your configuration.
      A network statement such as 192.168.2.150/24 is "technically" the same as 192.168.2.0/24 but I have no idea how the MacVlan driver or the Docker Plugin would interpret the first address. It's best to use 192.168.2.0/24.

      Another note, regarding the missing IP address for your server in the MacVlan section:
      From experience, I've found that trying to alter a MacVlan network configuration, after it has been saved the first time, didn't always "take" or "save". It's best to delete the MacVlan network and configure it again, with the correct entries.

      Since the Pi-Hole docker container's networking is based on the MacVlan driver, if MacVlan settings are changed, it would probably be best to configure a new container from scratch. So, the best bet would be to delete the MacVlan and the container, and start over using 192.168.2.0/24
      ___________________________________________________________________

      When the above is done, in the Docker plugin, your container's STATUS should be running. If it's running, the first test is going to 192.168.2.155/admin in a browser. If you can't get into the console, there's no point in going further.

      If you can get into the console, that's when you'd change your router according to your link above.

      If you have clients accessing your network using DHCP, it's easier to simply reboot them or, if they're devices (TV's), power them off and on so they'll pick up a new address in your reduced DHCP range, and the Pi-holes DNS address from your router.
      At the beginning I got DNS service not running but now everything is green and working thank you so much for all your help and great guide.
      Images
      • 2018-09-23_204917.jpg

        28.65 kB, 1,043×103, viewed 13 times
      • 2018-09-23_205025.jpg

        147.78 kB, 776×839, viewed 11 times
      • 2018-09-23_212840.jpg

        38.87 kB, 1,025×216, viewed 10 times
      • 2018-09-23_215341.jpg

        154.21 kB, 1,252×683, viewed 14 times
      • 2018-09-23_221712.jpg

        96.07 kB, 644×695, viewed 15 times
      • 2018-09-23_222327.jpg

        125.41 kB, 1,261×911, viewed 10 times
    • geaves wrote:

      your using the MAC address to fix the ip to a specific machine, this is not normal practise

      Of course it IS normal practice to use DHCP in the way it has been designed. You want to manage static IP addresses centrally and not by fiddling around with text files or config database entries on individual machines.

      @Nefertiti: can you provide output from 'armbianmonitor -u' when you're logged into OMV on your RPi via SSH? In case you use an OMV image older than 1 year this will produce only 'command now found' but if you started with OMV 3 after July 2017 we might get some insights.
    • tkaiser wrote:

      geaves wrote:

      your using the MAC address to fix the ip to a specific machine, this is not normal practise
      Of course it IS normal practice to use DHCP in the way it has been designed. You want to manage static IP addresses centrally and not by fiddling around with text files or config database entries on individual machines.
      What does this have to do with this thread....nothing....have you contributed anything to this thread to resolve the problem....no

      But you take one single comment out of context by cutting the end of the comment off and then proceed to apply your bit which serves no purpose!!
      What part of community forum do you not understand, you seem to take some sort of satisfaction in a "I know better than you do" attitude. Does this help anyone....no, but it obviously boosts your ego.
      As a moderator and as a forum member if you are unable to contribute to a thread to assist another member in resolving their problem, then "have sex and travel" because "willy waving" your knowledge is a distraction and totally unnecessary.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      What does this have to do with this thread....nothing

      The purpose was informing you that things do work differently than you think (since you're a forum user spending a lot of time sharing your knowledge with others). If @Nefertiti would have been told to simply assign a static IP address in his router for his Pi a lot of confusion and lost time could have been avoided.

      Next wrong assumption is 'eth0' being always the name of the active network interface of an OMV box. This is also something from the past (today we use so called 'predictable network interface names' and eth0 is already deprecated -- OMV users and especially people trying to help other forum users should stop thinking ethN would be the natural way of naming interfaces since with Debian 10 they're completely gone -- details) but there exists no reason at all to think eth0 would be the correct interface name (that's the stuff @Nefertiti lost most of his time with since on his installation eth1 seems to be the device in question and me asking him for armbianmonitor -u output is the try to get an idea why to probably improve OMV code to better deal with such situations).
    • tkaiser wrote:

      The purpose was informing you that things do work differently than you think (since you're a forum user spending a lot of time sharing your knowledge with others).
      Touche.....No I don't think I know!! Not only that most SOHO users do not have that functionality within their network, no dc, no pfsense and routers that do not allow mac filtering....So I work on the KIS principle. But thank you for the condescending comment :)

      tkaiser wrote:

      If @Nefertiti would have been told to simply assign a static IP address in his router for his Pi a lot of confusion and lost time could have been avoided.
      Post 8, tried that for whatever reason that didn't work or it didn't apply itself. Plus his router clearly states that fixed ip addresses are required to be outside of the dhcp scope.

      tkaiser wrote:

      lost most of his time with since on his installation eth1 seems to be the device in question and me asking him for armbianmonitor -u output is the try to get an idea why to probably improve OMV code to better deal with such situations).
      Again Post 8 clearly shows his interface as eth0 when he tries to change to a static ip. But running omv-firstaid to reset the network interface has renamed it, why?
      I changed my machine and searching the forum all I needed to do was to run omv-firstaid and run the network configuration, which I did, mine changed from eth0 to enp2s0 which I can locate in /etc/network/interfaces.

      tkaiser wrote:

      OMV users and especially people trying to help other forum users should stop thinking ethN would be the natural way of naming interfaces since with Debian 10 they're completely gone
      I thought the current omv was based on Debian 9? or is the above for future reference?

      Perhaps end users like myself should stop 'trying' to help others as we deliver assistance simply and clearly without the technical babble which they would not understand nor care about.

      Perhaps it might help if @flmaxey changed the howto on Pi-Hole to check the network interface name at the time of changing omv's dns setting and for the user to make a note of that as it will be required later in the guide.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      So I work on the KIS principle

      IMO no. @Nefertiti had the most simply setup one could imagine: he used a statically assigned IP address set by his router (basic DHCP functionality) and problems started once he tried to switch to a manual setup (with wrong MTU setting, maybe that was the culprit in the beginning -- don't know).

      I know you call this willy wanking (or insert any other insults here) but currently I try to get an idea what went wrong to improve OMV on ARM devices (yeah, I'm not after spending hours in the forums trying to help politely other users but I want to fix issues where they should be fixed in the first place so those questions/issues can be avoided altogether).

      Background information:
      • On the Armbian based OMV images networking setup is done entirely different to x86 installations where OMV's own routine adds the appropriate interface to OMV's config so that a network entry is already defined. On ARM this does not happen currently which allows users to use wrong settings (see MTU size): Last year I added automatic creation of the network node but this resulted in problems in networks with IPv6 enabled so I removed this in the images (spent 2 days on the problem -- situation with ARM due to most SoC families having own kernels is way more complex compared to x86)
      • When I try to setup manually a network node on one of my ARM boards the OMV UI only allows me to use eth0 but in my situation that's the wrong interface (see [1]). Based on this I don't trust that much into eth0 being displayed in @'Nefertiti''s screenshots. Hint: trying to debug this issue omv-firstaid fails with an error message (that looks like an unrelated bug with displaying the UI). That's why I asked for armbianmonitor -u output already multiple times
      • Two weeks ago we changed the way name resolution is set up in Armbian. I'm currently trying to get an idea how/whether this conflicts with the way OMV tries to configure those settings and I also try to figure out whether it's worth the efforts changing 'first boot' behavior of the OMV ARM images to create a an interface config automatically (that's the challenge compared to x86 where the user is forced to run a manual setup when installing)


      geaves wrote:

      Perhaps it might help if @flmaxey changed the howto on Pi-Hole to check the network interface name at the time of changing omv's dns setting
      Well, I've to admit that I don't understand this step at all. Why do I need to adjust DNS settings? And if I fear tracking on the Internet why exactly would I use Google's DNS servers then (or any other centralized -- if you fear someone tracking your Internet behavior then the best DNS server possible is your ISP's one).

      I set up Pi-Hole in a Docker container on my EspressoBin now skipping the 'create a static IP address and assign 8.8.8.8 as DNS' step entirely just creating a macvlan interface in Docker with the appropriate parent device (br0 in my case) and it simply works.


      [1] br0 is the needed interface, eth0 is not the right one (but is presented to me as only available interface in the OMV UI), so obviously the OMV routine to display the active network needs adjustments

      Source Code

      1. root@espressobin:~# ip addr
      2. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      3. link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      4. inet 127.0.0.1/8 scope host lo
      5. valid_lft forever preferred_lft forever
      6. inet6 ::1/128 scope host
      7. valid_lft forever preferred_lft forever
      8. 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
      9. link/ether de:be:4d:a1:31:84 brd ff:ff:ff:ff:ff:ff
      10. 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
      11. link/ether 0a:54:86:cf:d7:5c brd ff:ff:ff:ff:ff:ff
      12. 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 532
      13. link/ether f0:ad:4e:03:64:7f brd ff:ff:ff:ff:ff:ff
      14. inet6 fe80::f2ad:4eff:fe03:647f/64 scope link
      15. valid_lft forever preferred_lft forever
      16. 5: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
      17. link/ether f0:ad:4e:03:64:7f brd ff:ff:ff:ff:ff:ff
      18. 6: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
      19. link/ether f0:ad:4e:03:64:7f brd ff:ff:ff:ff:ff:ff
      20. 7: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
      21. link/ether f0:ad:4e:03:64:7f brd ff:ff:ff:ff:ff:ff
      22. 8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
      23. link/ether ba:23:5c:97:2f:ff brd ff:ff:ff:ff:ff:ff
      24. inet 192.168.83.69/24 brd 192.168.83.255 scope global dynamic br0
      25. valid_lft 858302sec preferred_lft 858302sec
      26. inet6 fe80::b823:5cff:fe97:2fff/64 scope link
      27. valid_lft forever preferred_lft forever
      28. 9: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      29. link/ether 02:42:b1:0c:b6:57 brd ff:ff:ff:ff:ff:ff
      30. inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
      31. valid_lft forever preferred_lft forever
      Display All
    • Nefertiti wrote:

      /---/ now everything is green and working t /---/
      :thumbsup: Have a good one.

      geaves wrote:

      Well done glad you got it sorted and it's working, my Pi-Hole shows eth0 as well even though it isn't :)
      And you too. :) (Let's ignore the insurgent or this thread will get butchered up, as it spins down yet another rabbit hole.)
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)

      The post was edited 1 time, last by flmaxey ().