ken-ji

Just a thought, but Wifi-only users might want to consider getting a "real" router (I used a Mikrotik hAC router before) and have it link to the local Wifi and 'NAT' off the rest of the ethernet and Wifi clients. So your servers, desktops, laptops can connect to your LAN/Wifi and still have access to the residential Wifi (albeit double NAT'd) and be relatively secure from everybody else on the residential Wifi. I had to stop this as my solution as I was trying to run a connection through a solid foot of concrete flooring which would horribly attenuate the signal. But I would not hesitate to try this if I was in a similar situation.

You will always loose rights to a file you rsynced over will be created by root, unless you use -p option (case sensitive) in which case it will be created with the same ownership as the source files - which might not be applicable on the destination unraid the quick test is to use the ssh command if you can type ssh root@IP_OF_SERVER echo Hello and you get back "Hello" then rsync will not have any issues running... you can replace the "root" if you are using a different user on the other server You can use openvpn between your unraid and hers, but its kinda hard and might be better/easier if the openvpn was established your and her router (that way the router GUI will do all the hardwork for you)

Just to make things clear for everybody. Docker networks do not have a real DHCP server in the the usual sense. Docker networks do not interact with a DHCP server on that subnet either What docker simply does is it grabs the next free IP in the docker network, and assign it to the container. If the container stops (or leaves the network), the IP is automatically marked as free and available for the next container that requests an IP. The correct way to have DNS-like names is to do docker linking - which I don't like as its messy and doesn't persist across reboots The other correct way that's persistent is to assign IP addresses to each container that needs it and add it into your LAN's DNS server.

Gmail supports per application passwords: cf https://support.google.com/accounts/answer/185833?hl=en Then there's pushbullet (free), pushover (paid), slack(free), and the capability of making your own... and a few more I have no idea about.

if you have 1.2 MB/s uploading to your folks, you are already using ~12mbps of your 20mbps so it might be normal as internet overheads and other stuff can clog your pipes. It can be better, as I can do about 2.2MB/s given the same situation 20up/50down on the other end. In my case, The whole connection is wrapped in something similar to Zerotier - a pair of Mikrotik routers running Ethernet over IP with IPSEC to do site to site VPN.

I can only speculate, but I think if unRAID has multiple IP on multiple VLAN, the docker subsystem gets confused with regards to using a different VLAN per interface.perhaps its a bug with the automatic creation of the docker networks on VLANs where unRAID has an IP and network information. What you can try and its what I'm using is to have no unRAID IP on the VLAN so that unRAID is not accessible on that VLAN; this disables the auto creation of the docker network br0.x, which you then manually create and fill out the desired details.

Seems like the UI doesn't fully support the custom bridge network yet. (Haven't had a use case for it myself)

Do you think it would sell very well?

This is normal since your are mixing and not controlling the way you access all the files. I have my server mitigate this by making all the dockers and all the SMB accesses are done as the nobody user; but I still get tripped up by some of my directories being owned by root. This happens because I ssh in and perform manipulation of files as the root user - can't do it as nobody - since nobody can't quite login... meh...

drop the comma Rule: 10.0.0.100(sec=sys,rw) 10.0.0.101(sec=sys,rw)

So this is what needs to happen for SSH to work without prompts, or errors after a reboot. Unraid server: /root/.ssh directory with permissions (700) /root/.ssh/id_rsa file needs to exists with the permissions (600); this is your private key /root/.ssh/known_hosts with permissions (600); this file contains the public key of the servers you've connected to and stops the prompting of the untrusted host/ unknown keys; if the server changes (or a MITM attack occurs) this will prevent SSH from connecting until the server public keys match or is scrubbed from the file /root/.ssh/config with permissions (600); this specifies some config options, like the server aliases, keyfiles, etc - this is not necessary if you are connecting to the other server as root, using the server IP address (or a name that your Unraid server can resolve into its IP adrress) (optional) /root/.ssh/id_rsa.pub file; this is the public key pair to your private key Target server: /root/.ssh directory with permissions (700) /root/.ssh/authorized_keys with permissions (600); this contains the public key part of your private key (1 pub key per line of the file; can contain multiple keys) since Unraid is a RAM-disk OS, you just need to make sure that the above directory and 2+ files are created/restored upon reboot. There are a bunch of scripts/go file modifications above to this extent. Since you mentioned your Target is FreeNAS and IIRC, the root partition is on flash or HDD, so you just need to create the 2 directory and file just once. You only need one key-pair. Specially since you are doing one way transfers (Unraid connects to FreeNAS, FreeNAS doesn't connect back) Take your time to get this right, as SSH is a very strict protocol and clients will often just fail the connection if something feels off.

cd /root/.ssh cp /boot/config/sshroot/* /root/.ssh/ chmod 600 * Odd that it caused you issues... but you can change these to cp /boot/config/sshroot/* /root/.ssh/ chmod 600 /root/.ssh you might want to read the entire thread for minor corrections and suggestions (I kinda know this stuff already so I might misread a few things here and there)

This means you entered a pass phrase when you generated the rsync key Please try again with the ssh-keygen command and pay attention to the part where it prompts you for the passphrase (you just hit enter)

@xman111 You only need to do the mkdir .ssh; chmod .ssh part once. since freeNAS lives on a drive partition, the changes will persist. you only need that part of script for Unraid, as the .ssh directory is lost every shutdown/reboot. in you instance, just run this on the freeNAS CLI cd ~ mkdir -p .ssh chmod 700 .ssh mv Tower-rsync-key.pub .ssh/ cd .ssh/ cat Tower-rsync-key.pub >> authorized_keys chmod 600 authorized_keys

Make sure your FreeNAS is running a version of a sh/bash/zsh I think the if command will fail if you use it on csh/tcsh