Dmitry Spikhalskiy

Members
  • Posts

    70
  • Joined

  • Last visited

Posts posted by Dmitry Spikhalskiy

  1. The above solution originally published by @Vivent that includes setting "Include listening interfaces" works for me with the latest 6.12.4-rc18 and 6.12.4-rc19. unRaid UI, shares, and docker containers are fully available for other nodes in Zerotier virtual network again.

    Important, if you upgrade from 6.12.3 and have the listening interfaces already set up as suggested: wipe them out, save, and put your zerotier gateway name back again. It was a necessary step for me to make things work after 6.12.3 -> 6.12.4-rc18/19 upgrade.

    • Like 1
    • Thanks 2
  2. There will be no updates from me here. There were no changes in the container and its configuration and the same exact container with the same exact configs continues to work successfully on Servers with other Linux distributions. So the problem is in the Unraid update and the fix if any will come from the Unraid team.

     

    What I personally observe, with the following Docker settings at least, Zerotier can connect to the service just fine, and other devices in the virtual network can successfully ping the Unraid virtual IP address. And I even can open a directory listing on <unraid virtual ip>:6080. But Unraid UI and docker container ports are not available for devices in the virtual network.

     

    My only guess is that 6.12 brought some unannounced changes in isolation causing it. iptables? nginx? I can't figure it out.

     

     

    Screenshot 2023-07-13 at 8.08.51 PM.png

  3. @Elmojo Shouldn't be happening. Next time it happens, try to check the logs of the container. They are available by clicking on the icon in the Docker tab and choosing Logs.

    Also, check the logs on your UnRaid server too around the time it happens.

    Some IO problem or a crash on your specific configuration may be causing it.

    • Like 1
  4. @Moepsindi Why do you run

    ./zerotier-cli

    at all? This container doesn't have runnable `zerotier-cli` in the root of the file system. So, this command is not expected to work. zerotier-cli executable is in `/usr/bin/zerotier-cli`.

     

    `zerotier-cli join` or `zerotier-cli info`, etc will work in this container.

  5. 16 minutes ago, air1kdf said:

    You may want to consider putting this in the install guide, as this was a requirement for mine to work.  Thank you for your work.

    @air1kdf this container does exactly that on every start. If this command helped you, you either put an incorrect networkId in the container settings or a simple restart of the container would also help. 

  6. 6 hours ago, final said:

    In unraid 6.10.2, the application cannot be registered in the zerotier network, can it be fixed?

    This app/container works fine with Unraid 6.10.2 or 6.10.3, there is nothing to fix.

    You have to debug your own environment. In the root post you can find steps that you should do to make a meaningful information about your issue. Somebody in this thread may help if you provide enough info.

  7. 4 hours ago, Michael Kaaber said:

    Hi Dmitry,

    Do you have time to update to latest Version?

    Regards

    Michael

    1.10.0? I will skip this one.

    1. I see several issues in github that after an upgrade specifically to 1.10.0 users installations stopped working. I inclined to wait for at least first patch version. https://github.com/zerotier/ZeroTierOne/issues/1692 https://github.com/zerotier/ZeroTierOne/issues/1695

    2. I'm not sure what's going on with 1.10.0. The latest code changes in zerotier github are for 1.8.10. There is neither Release Notes related to 1.10.0 (https://github.com/zerotier/ZeroTierOne/blob/master/RELEASE-NOTES.md), nor code changes between 1.8.10 - 1.10.0. I don't want to upgrade to some version that is stated just on their website and completely doesn't exist in the code repository. I guess it's ok if they suddenly went closed source, but it's not ok that I can't find any information or statement about it around at all.

  8. Quote

    Why don't you use the official Zerotier image for the template? Does your image contain custom changes for Unraid?

    Yes, it's a custom image.

    First of all, it's on Alpine and it's much lighter. Zerotier official image moved to debian at some time, I took their image at that time and maintain myself:

    https://github.com/Spikhalskiy/zerotier-containerized/blob/master/Dockerfile

    Second, it has a custom starter script that wires parameters the right way:

    https://github.com/Spikhalskiy/zerotier-unraid-docker/blob/master/Dockerfile

    It doesn't have any changes to zerotier binaries and install them from the official sources.

    It's all on github, suit yourself.

  9. 1 hour ago, Caldorian said:

    Just installed this on my unraid server. Any time I try to run a zerotier-cli command from the docker instance, I get a dozen lines of the following before the command results:
     

     

    Any fix for this? Other then that, things look to be working well. I also installed it on my raspberry pi/pi-hole instance to use a bridge to get access to my whole internal network. Plan is to do the same on a second Pi at my parent's for remote access to their stuff.

    Not I'm aware of, but I didn't spend any time resolving it. Stuff works just fine and it's safe to ignore.

    If it bothers you to the extend of looking for a solution, contributions are welcomed!

  10. 34 minutes ago, rrr01 said:

    Hi. I found a serious issue of this docker container when used in conjunction with an OpenWrt VM. Auto-start of this docker container makes me unable to access the unraid server after rebooting.

     

    I used an OpenWrt VM as my router for internet access as well as a gateway for Zerotier virtual network. As shown below, the IP of the router in Zerotier is 10.147.17.131 and my physical subnet is 192.168.31.0/24. I have a Zerotier docker container on my unraid as a backup.

     image.thumb.png.7a81d64658d7061da8048089914b1fe4.png

     

    When I reboot, as the unraid server boots before the OpenWrt VM, it is not able to get the correct route information for the physical NIC. Instead, it places the route acquired from Zerotier first. This makes it impossible to access the unraid server from LAN or from Web, as the route is wrong and it will keep trying to connect to anything in the subnet including the OpenWrt router through the Zerotier gateway at 10.147.17.131. 

     

    I speculate this behaviour can be avoided if either 1. like other clients, add an option to disallow route through zerotier 2.. the container configures the route table after the correct one is acquired.

    Hey.
     

    Are you sure you are solving the problem from the right end?

     

    Quick look at articles and discussions like https://zerotier.atlassian.net/wiki/spaces/SD/pages/193134593/One+Port+Linux+Bridge

    https://www.google.com/amp/s/amp.reddit.com/r/zerotier/comments/dc03me/having_some_trouble_with_managed_routes_static/

    makes me think that you should be playing with your router, not this zeroiter container on your unraid.

     

    This symptom “This makes it impossible to access the unraid server from LAN” especially points me in this direction. Playing with managed routes on unraid will change what can be accessed from the unraid. But it shouldn't affect availability of unraid for other computers in local network. This sounds like a router setting problem for me.
     

    Let me know. If you want to have basically ‘zerotier-cli set network_id allowManaged=0’ available through the image settings - I can do it for you, no biggie. But I don't think it's a root of your problem and there is a high chance you approach the problem from the wrong end.

  11. 4 hours ago, technorati said:

    Ever since the update to 1.6.2, my unRAID machine no longer joins my ZT network, and when I try to debug inside the container, I get errors from the zerotier-cli tool:

     

    
    zerotier-cli info
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    zerotier-cli: /usr/lib/libstdc++.so.6: no version information available (required by zerotier-cli)
    200 info XXXXXXXXXXX 1.6.2 OFFLINE

    I have tried deleting the container and reinstalling from CA, but it comes back with the same issue.

     

    Rolling back to spikhalskiy/zerotier:1.4.6 has fixed the issue for now.

    "no version information available" messages are fine, you can ignore them, it's not what causes the issue.

  12. 21 minutes ago, Asmithcveg said:

    That's what I figured sadly. The terminal returns "ls: cannot access '/dev/net/tun': No such file or directory"

    So, you probably want to switch the discussion into Unraid main support threads, because it's a problem with your Unraid linux kernel configuration most likely. Unraid should have this device mounted by default.

    Some reference that could help:

    https://unix.stackexchange.com/questions/501403/tun-module-loaded-but-openvpn-dev-net-tun-no-such-file-or-directory

    I would examine:

    grep CONFIG_DEVTMPFS /usr/src/<whatever you have here>/.config

    and ensure that it's

    CONFIG_DEVTMPFS=y
    CONFIG_DEVTMPFS_MOUNT=y

    (DEVTMPFS should auto-mount devices like /dev/net/tun)

     

    Also I would at least try to do

    rmmod tun
    modprobe tun

    to try to reload the module.

     

    I think that the output of these commands could be useful for the Unraid support thread anyway.

     

  13. 33 minutes ago, Asmithcveg said:

    Yup! Installed it straight from community apps, and it is set to run with privileges.

     

    Edit: I should also point out that no files, data, etc. is present within the appdata folder for this container.

    > Edit: I should also point out that no files, data, etc. is present within the appdata folder for this container.

     

    This is ok, Zerotier can't start to put anything there yet.

     

    > Yup! Installed it straight from community apps, and it is set to run with privileges.

     

    No idea in that case for now.

    https://zerotier.atlassian.net/wiki/spaces/SD/pages/7536656/Running+ZeroTier+in+a+Docker+Container

    Here is Zerotier explanation about /dev/net/tun and what should be done to have an access to it.

     

    I pass required parameters "--device=/dev/net/tun --cap-add=NET_ADMIN --cap-add=SYS_ADMIN" here in the configuration of the container published in CA: https://github.com/Spikhalskiy/docker-templates/blob/master/zerotier.xml#L40

    And usage of these parameters is allowed by Privileged: ON.

     

    You will have to debug your own configuration I afraid, because the problem is probably local to your setup and probably your kernel configuration.

    What does

    ls -la /dev/net/tun

    say if you run it in the server terminal?