ken-ji

I guess I was pissed. But I should have seen it coming, I just didn't get to participate the RC to have seen this actual effect. Its still annoying that its an all or nothing approach right now.you should have left custom networks with un-address-ed interfaces alone. maybe that would be a better compromise.

Its not "crippled"... just that it now imposes some constraints that I consider naive and annoying. * Any interface with an IP address will have its custom docker network nuked without asking the user, and a new custom network setup based on the details of the IP address assigned. ** thus a new requirement that unRAID have an unnecessary IP in all custom docker networks. This requirement may sound trivial and not an issue, as containers can't reach unRAID on that IP, but i think users will get confused still and wonder why they can't reach unRAID on that IP. * Any other custom network is nuked away without even giving the user the option to use it. * and worse, there's no behavioral off switch. Workaround: the custom network can be defined after the docker service has started, but dockers on this custom network will no longer autostart. So now all my containers running on a separate VLAN won't even run since the custom docker network is now missing. My PHP sucks, but I think I can make a manually configured plugin to fix this silly limitation for now.

I'm sorry but I'm going to consider Docker network support in 6.4 too simple and naive. With the auto clean up of docker networks, it completely broke my system post upgrade. I'm now going to have to work out a correct way of setting up custom docker networks, without assigning unRAID an IP for my own simplicity. And still having the containers come up automatically. Do you have any suggestions?

Well the default of the Docker is to run as the user nobody which has all the necessary permissions to be accessible by guest/(insecure share) I think the missing step is to actually define the Dropbox share user the Shares TAB of the unRAID Web UI Because if you didn't define it there, it will pickup/assume some settings that might not make any sense to your configuration (public share, etc) Do take note that by default a user share with a cache drive is a recipe for data loss, since any changes to your Dropbox files will result in the mover running at some point causing Dropbox to delete the underlying files. tl;dr the Dropbox share should be a cache-only or share-only. Do not try any of the other settings. The app running is the default one by Dropbox and has no "dumbo-mode" UI's . There's no site/page either - 17500 is needed for LAN syncing - Dropbox will happily send/receive updates from any of your Laptops/Desktops One known issue with Dropbox that I haven't solved is that upon restart of unRAID Dropbox thinks its a new PC and wants to be linked again. I haven't figured out what's causing this and have yet to get a controlled environment to test and try to fix with.

@bonienl I'm thinking the docker network support should have a more I-know-what-I'm-doing-so-let-me mode. Or at least have an option to create the network for interfaces without IP addresses to allow people with more complex networks to use most of the UI without having to do really ugly workarounds like blowing away docker networks to get what they want. My particular use case is that I do macvlan networks on another vlan, but unraid is not allowed to have an IP on that vlan. Which increases security and control.

6.4 is supposed to auto create docker networks for any interface that has an IP upon docker startup. I think this is what is altering your settings. I'm not on 6.4 yet. Maybe @bonienl can enlighten us.

Yeah, docker networks currently do not communicate with an external DHCP server - there was some talk about somebody writing a docker engine plugin to do that, but that has yet to materialize - so the need to specify a subnet for docker containers to use outside of the DHCP server allocation range is necessary.

Post your network details and what you want the container ip to be. Post the output of docker network ls and docker network inspect <network> where network is any network listed by the ls command other than bridge, host and none I'll see what you need to run and change

Its not a true vlan. So the use of a different subnet puts two logical networks on the same broadcast domain, allowing spying on each other but no true communication, as subnet 1 has no idea how to route to subnet 2 (the gateway has in all likelihood a single ip on subnet1 and nothing on subnet two)

Ok, did a bit of research. Assume the following: local network gateway: 192.168.1.1 local network: 192.168.1.0/24 DHCP range: 192.168.1.64/26 (64-127) unRAID server IP: 192.168.1.5 unRAID interface: br0 Docker network: localnet Docker network range: 192.168.1.128/26 (128-191) Then we'll need another IP for unRAID server to use with the docker network unRAID server IP2: 192.168.1.6 So in this case after you'll need to run the following commands: ip link add br0.host link br0 type macvlan mode bridge ip addr a 192.168.1.6/24 dev br0.host ip link set up dev br0.host The last line is very important, as by default, the interface would be down (not connected)

Yeah all you really needed to do is modify /boot/config/ssh/sshd_config to: read authorized keys from /etc/ssh or /boot/config/ssh (as /boot/config/ssh/* gets copied to /etc/ssh upon startup of the ssh server And for bonus points, you probably want to modify ssh_config to read the default private keys from /etc/ssh as well.

Wait, in 6.4, an IP must be assigned to Docker VLAN for it to function with the GUI? Hmm... Dunno if that will break things for me...

My article is for the 6.3.x series as there is no GUI support then. You are on 6.4 and the GUI has native support this - which I'm not sure how to use ATM since I'm still on 6.3.5 But you need to be sure to have the following info: 1. A router IP for each subnet (this is usually 192.168.x.1 or similar) 2. A DNS server for each subnet - again usually the router 3. A DHCP server for the docker subnets is not necessary for the docker network as dockers still used a built-in internal address assignment scheme. That normally won't work: as the docker network would be created as you have specified and thus not routable on a different subnet the docker containers don't allow the internal user to fiddle with network settings (special cases do apply, but then permissions need to be set and applied to the containers to do that in the first place) you're VMs do not have routing enabled (normally they won't) Also, you failed to note what network your VMs show up in. the initial default is an internal virtual network (vibr0) in unRAID that the docker containers can't reach.

NFS is definitely better than CIFS/SMB. Performance is the reason they still use it with the big name Fileservers and Hypervisors Companies selling switches and routers use FTP and NFS as a benchmark of throughput as both are simple protocols that can easily do near wirespeed.

* Yes, you can run multiple docker networks. what is important and not allowed is to have multiple docker networks with the same gateway address * --parent is mandatory as it tells docker where to attach the macvlan network.

see this:

There's a plugin call User Scripts. It'll help you manage script files on the flash drive along with scheduling on when to run them. This will let you do what you want without having to mess with dockers But the script on pfsense is probably the real right way to do it.

Disconnect unRAID by pulling out the lan cable first. Then try to ping the unRAID IP. That'll quickly let you know if anything else is using unRAID IP.

Please refrain from setting unRAID IP to a DMZ. That will only invite more security issues - possible worst case for a home user - all files deleted/ransomed, then the unRAID server is used as a jumpbox to further compromise more stuff in your home network - including your router That warning said. DMZ of unRAID for dockers won't work since docker containers by default only have the port that is mapped in the configuration as accessible from outside the host. You probably should post diagnostics, that would show if you have some issues. (Just realized that you failed to mentioned how transmission is installed on unRAID)

Run the memtest option on the unraid usb during startup for several hours/passes. This will help rule out memory seating / chip issues too.

When unRAID is started up, you can login from the console and type diagnostics the resulting zip file will be at logs directory in the flash drive. If you can't get it via the flash share, you can shutdown unRAID, and pop the USB in another PC to the diagnostics file. I don't think anybody can give you help without anymore details.

Well /etc/systcl.conf is just a config file. Changing the contents won't do anything unless sysctl is called again referencing the the conf file But, the sysctl call that does that happens so much earlier in the boot process, so modifying sysctl.conf doesn't help at all.

No need, the command just tells sysctl to modify the settings from your new config file, while the normal bootup scripts would have already used the standard config file to set up much earlier on in the boot up process. you could actually just invoke sysctl -w setting=value multiple times in the go file, but this way there will be just one other file to maintain for tweaks later on

You can do it they way I do Place the new lines in a new config file somewhere in the usb, then modify the go file to execute /sbin/sysctl -p /boot/config/sysctl.conf

Linux is case sensitive. change the fstab in Mint to match the shares in unRAID. ie 192.168.1.9:/mnt/user/tv ->192.168.1.9:/mnt/user/TV