johnieutah

Members
  • Posts

    330
  • Joined

  • Last visited

Posts posted by johnieutah

  1. 17 hours ago, itimpi said:

    If you want to continue using macvlan then make sure bridging is disabled on eth0.

     

    Are there any significant differences? Everything appears to be working on first glance. Only issue I came across was with the Unifi docker and the host name not being resolved. Using the ip address has fixed it for now.

  2. Thinking of jumping from 6.10.something up to this. Or should I take an intermediate release first?

     

    I‘ve seen macvlan and ipvlan mentioned a few times for things to watch out for but have no idea what this setting is. I haven’t changed anything from the docker defaults I don’t believe…

     

    Thanks for any help.

  3. I’m new to the Mac world. Previously I used windows and syncback to synchronise local folders to Unraid shares.

     

    Now I’m trying to get a replacement backup process in place using rsync with SSH. I've got it mostly working without SSH, now I want to automate the authentication step.

    Here’s the basic rsync script:

     

    rsync -rtzPi --progress --stats --delete --exclude=".DS_Store" "/Users/matt/Documents/" "root@toaster:/mnt/user/Documents"

     

    I have created a public/private key pair using ssh-keygen. 

    I then used ssh-copy-id to transfer these to Unraid. I believe this has worked as the key is there in /boot/config/ssh.

     

    I'm not sure what to do now. Every time I run the above command, it asks me for a passphrase (not password) for the key. Obviously I've missed something in the configuration step.

     

    Any help appreciated.

     

     

  4. Hi. After many years of using this docker without issues, I just updated - yeah my fault, everything was running great but the old "update" docker image button was tempting me too much... - anyways, now I am having an issue with Airplay bridge:

     

    Restarting Squeeze2raop after crash: /config/cache/InstalledPlugins/Plugins/RaopBridge/Bin/squeeze2raop-linux-x86_64 -Z -I -b 192.168.1.30 -f /config/logs/raopbridge.log -x /config/prefs/raopbridge.xml [19:19:00.043] main:1572 Starting squeeze2raop version: v1.5.3 (Dec 25 2023 @ 19:09:38) [19:19:00.043] Start:1297 Cannot load SSL libraries [19:19:00.044] main:1676 Cannot start, exiting

     

    Any ideas?

     

    Thanks.

  5. On 10/4/2023 at 12:31 PM, jpowell8672 said:

    Run Tools > Update Assistant first then follow release notes upgrade procedure:

     

    Version 6.12.4 2023-08-31

    Upgrade notes

    Known issues

    Please see the 6.12.0 release notes for general known issues.

    Rolling back

    Before rolling back to an earlier version, it is important to ensure Bridging is enabled:

    Settings > Network Settings > eth0 > Enable Bridging = Yes

    Then Start the array (along with the Docker and VM services) to update your Docker containers, VMs, and WireGuard tunnels back to their previous settings which should work in older releases.

    Once in the older version, confirm these settings are correct for your setup:

    Settings > Docker > Host access to custom networks

    Settings > Docker > Docker custom network type

    If rolling back earlier than 6.12.0, also see the 6.12.0 release notes.

    Fix for macvlan call traces

    The big news in this release is that we have resolved issues related to macvlan call traces and crashes!

    The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report.

    If you are getting call traces related to macvlan, as a first step we recommend navigating to Settings > Docker, switch to advanced view, and change the "Docker custom network type" from macvlan to ipvlan. This is the default configuration that Unraid has shipped with since version 6.11.5 and should work for most systems. If you are happy with this setting, then you are done! You will have no more call traces related to macvlan and can skip ahead to the next section.

    However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode.

    For those users, we have a new method that reworks networking to avoid issues with macvlan. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

    Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution

    Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)

    Settings > Docker > Host access to custom networks = Enabled

    Note: if you previously used the 2-nic docker segmentation method, you will also want to revert that:

    Settings > Docker > custom network on interface eth0 or bond0 (i.e. make sure eth0/bond0 is configured for the custom network, not eth1/bond1)

    When you Start the array, the host, VMs, and Docker containers will all be able to communicate, and there should be no more call traces!

    Troubleshooting

    If your Docker containers with custom IPs are not starting, edit them and change the "Network type" to "Custom: eth0" or "Custom: bond0". We attempted to do this automatically, but depending on how things were customized you may need to do it manually.

    If your VMs are having network issues, edit them and set the Network Source to "vhost0". Also, ensure there is a MAC address assigned.

    If your WireGuard tunnels will not start, make a dummy change to each tunnel and save.

    If you are having issues port forwarding to Docker containers (particularly with a Fritzbox router) delete and recreate the port forward in your router.

    To get a little more technical...

    After upgrading to this release, if bridging remains enabled on eth0 then everything works as it used to. You can attempt to work around the call traces by disabling the custom Docker network, or using ipvlan instead of macvlan, or using the 2-nic Docker segmentation method with containers on eth1.

    Starting with this release, when you disable bridging on eth0 we create a new macvtap network for Docker containers and VMs to use. It has a parent of eth0 instead of br0, which is how we avoid the call traces.

    A side benefit is that macvtap networks are reported to be faster than bridged networks, so you may see speed improvements when communicating with Docker containers and VMs.

    FYI: With bridging disabled for the main interface (eth0), then the Docker custom network type will be set to macvlan and hidden unless there are other interfaces on your system that have bridging enabled, in which case the legacy ipvlan option is available. To use the new fix being discussed here you will want to keep that set to macvlan.

     

    https://docs.unraid.net/unraid-os/release-notes/6.12.4/#:~:text=This release resolves corner cases,properly shut the system down.

    Thanks for this. I'm not sure what my setup is running, I guess macvlan:

     

    2037419677_Screenshot2023-10-18at21_49_30.thumb.png.f5bf0b353713db036e4a6880e8bd225f.png

     

    I really don't understand what any of this means though TBH. In the past I've updated unraid and it's usually worked fine.

  6. On 3/15/2023 at 9:24 PM, JonathanM said:

    Install windows in a VM on the macbook?

     

    If you know what you are doing, it's easier to do the moves directly with the unraid terminal, mc is really convenient. Just don't stray outside /mnt/user unless you know what you are doing.

    Thanks for the reply.

     

    I didn't really want to go down the VM route for this simple task... I figured this was a setting or something that I can change in Finder, or maybe on the Unraid side.

     

    I would do the move of data locally using MC, but I need to merge folders and my understanding is that this is not so straight forward on the command line without resorting to rsync.

     

    Thanks.

  7. Hello!

     

    I am new to MacOS so this is probably obvious to someone...

     

    I have an Unraid server with various SMB shares. I want to move files already on a share to another location (on the same share). Under Windows this would happen pretty much instantly. On my Macbook, it always copies the files locally, and then pastes them back to the new location on the server. So it takes ages.

     

    Any ideas? Much appreciated.

  8. On 6/9/2022 at 1:20 PM, jademonkee said:

    Yeah, backup in Unifi, and if you have a recent "CA Backups" of your apps, that would be good, too.

    Also make sure you're on the latest firmware for your Unifi devices.

    Then just change the tag and away you go.

    Perfect, worked a treat.

    Only thing worth noting was a pop-up on logging into the Controller about my "wifi networks no longer being something something something" (yeah it disappeared before I could fully register it).

     

  9. On 4/28/2022 at 11:12 AM, jademonkee said:

    I mostly prefer the new interface.

    There's heaps of other changes since v5. You can see the changelogs from v6 > v7 here: https://community.ui.com/releases/UniFi-Network-Application-7-0-25/3344c362-7da5-4ecd-a403-3b47520e3c01

    And of course there's even more from v5 > v6

    Can I jump straight from my current version to v7.x, or do I need to make an intermediate jump?

     

    Do we have another recommended stable version to upgrade to like with the 5.14.23-ls76?

  10. As someone also with a HP gen 8 server, albeit with the Celeron processor, is it safe to update to this release?

     

    Just to throw my 2p into the hat, definitely agree that the update should absolutely be bullet proof and warn me if my hardware config may not be valid. Regular users to do not read change logs! Fact.

     

    Other than that piece of feedback, great job guys.

  11. On 1/6/2021 at 9:29 PM, Hoopster said:

    Yes.  Update through the Docker tab in unRAID and not in the UniFi application.  You can update firmware through the UniFi app, but you should not update the app itself that way.

     

    If you update with the :latest tag you will end up with a version 6 release of UniFi with which most still have issue.  You should use a version-specific tag such as :5.14.23-ls76 instead.

    Thanks this worked great.

     

    A final question regarding device firmware updates. Are these normally ok to update or is caution advised as well?

  12. On 12/14/2020 at 9:35 PM, wayner said:

    If you make this change then won't you permanently stay on that version until you change the repository field info?  But I guess maybe that is ok for now.

     

    There may be folks wanting to stay on Controller versions for a while as a lot of hardware will become deprecated in March 2021, like my four UAPs, unless you stick to old controller versions.  I appear to be on 5.12.35 which appears to be about a year old.

    Thanks for the info.

     

    So basically, although I am currently using the "latest" repository, because I haven't upgraded in a year since initial installation and am now on an outdated version, changing the repository tag is enough?

     

    Am I right in thinking we should not be updating the application through unifi itself but rather through the docker repo?

     

    Cheers!

  13. 4 minutes ago, Hoopster said:

    It's a piece of cake. 

     

    Just put 'linuxserver/unifi-controller:5.14.23-ls76' in the repository field of the container then save and the docker container will restart and download that specific version.

    Will that not mess up my database or will it auto update accordingly as this is a supported update path?

     

    Cheers

  14. 1 hour ago, PeteAsking said:

    @sage2050

     

    I guess try running the 5 version with tag linuxserver/unifi-controller:5.14.23-ls76

     

    As it has been mentioned many times in this thread, it really is the best version available currently, and does everything and more than the current 6 release. There is no benefit, unless you are wanting to help unifi over on their forums find issues and fix them, to using anything else. For a business deploying the controller for a client, I cant imagine using the 6 release. Sounds like a nightmare.

     

    Pete

    I am looking at upgrading to this very version... at the moment I am running 5.12.35 BUT this is from the linuxserver/unifi-controller:latest tag. I am not sure how to easily change tags without breaking everything... or is it easier than I think?
     

    Any help appreciated. Cheers

  15. Hello all. Hoping for some quick help here as I need to gain access to my unifi controller which runs off my unraid server...

     

    Everything has been running fine, since yesterday I am no longer able to boot the server. I connected a monitor and took a picture of the output.

     

    No I don't get to a command prompt.

    I have done a chkdsk and windows states there are no issues.

     

    I have a backup from a few months ago when I did the update to Unraid v6.8.3.

     

    Thanks for the support.

    IMAG3653.jpg

  16. On 5/27/2020 at 11:45 PM, dlandon said:

    Go into LMS settgings and you can browse the /config/playlists folder.  You can browse to the appdata/LogitechMediaServer/playlists folder and check the contents.

    Thanks it all seems to be working perfectly now and I have moved all playlists over from the old location. I did have to do a full rescan of the library as rescanning only playlists ended up with everything being duplicated.