ken-ji

I've pushed a new version of my dropbox image containing the current version of dropbox. I've had to work out how to automate building - now that Docker autobuilds are a paid option. and I didn't want to move off docker.io registry for the time being.

I don't think the UI supports custom virtual nics. You'll have to configure it yourself AFAIK

Hmm, I'm stumped. I'll check to see if there's anything in the Dropbox headless client - they really don't give it as much support as they should.

Hmm. should be instant, but running `dropbox.py status` should be returning `Syncing...` not `Starting...` `Starting...` means the daemon is not running correctly... Can you try restarting the container, then running `ps xafu` as the root user inside the container? Mine returns this bash-4.3# ps xafu USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 243 0.2 0.0 18012 3064 pts/0 Ss 05:49 0:00 bash root 251 0.0 0.0 17684 2216 pts/0 R+ 05:49 0:00 \_ ps xafu root 1 0.0 0.0 17880 2840 ? Ss 05:43 0:00 /bin/bash /usr/local/bin/dockerinit.sh nobody 20 5.5 1.3 4839120 444748 ? Sl 05:43 0:19 /dropbox/.dropbox-dist/dropbox-lnx.x86_64-135.3.4177/dropbox root 21 0.0 0.0 4376 664 ? S 05:43 0:00 sleep 86400

that's the wrong command. Not sure on what's the values in 6.10rc2 but in 6.9.2 its root@MediaStore:~# sshd -T | grep pubkeyaccepted pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa ssh-rsa is at the very end

Please do realize that the thread is "solved" since its by docker design. Docker will not allow the host to talk to containers that are bridged using macvlan (default) I think 6.10rc1 allows ipvlan - which might work, so you should see if it solves the issue. As for the issue with Docker host access shim failing, well, it should be discussed on a different thread as this one was just asking about access to containers on br0

So i tried to mount it remotely via Terminal /mnt/user/isos <world>(ro,async,wdelay,hide,no_subtree_check,fsid=121,anonuid=99,anongid=100,sec=sys,insecure,root_squash,all_squash) This is my public share (I can't mount my private shares as they're open only on the LAN and I'm currently away) I'm not sure if I have actual read access to some of the files, since access is squashed to nobody, but I think that's an issue that can be resolved. My only Macbook is my employer's and this is the first time I've tried to access Unraid from it. And here's what happened. (Ishikawa is my Macbook, and Unraid is 192.168.2.5 over VPN) Ishikawa:~ kenneth$ mkdir RemoteTest Ishikawa:~ kenneth$ mount 192.168.2.5:/mnt/user/isos RemoteTest Ishikawa:~ kenneth$ mount /dev/disk1s1s1 on / (apfs, sealed, local, read-only, journaled) devfs on /dev (devfs, local, nobrowse) /dev/disk1s5 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse) /dev/disk1s3 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse) /dev/disk1s6 on /System/Volumes/Update (apfs, local, journaled, nobrowse) /dev/disk1s2 on /System/Volumes/Data (apfs, local, journaled, nobrowse) map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse) 192.168.2.5:/mnt/user/isos on /Users/kenneth/RemoteTest (nfs, nodev, nosuid, mounted by kenneth) Ishikawa:~ kenneth$ cd RemoteTest/ /Users/kenneth/RemoteTest Ishikawa:RemoteTest kenneth$ ls -l total 51486120 -rwxrwxrwx 1 root wheel 2147483648 Jul 17 21:30 BigSur-install.img -rwxrwxrwx 1 root wheel 157286400 Jul 17 21:24 BigSur-opencore.img -rw-rw---- 1 kenneth _lpoperator 417333248 Dec 9 2013 CentOS-6.5-x86_64-minimal.iso -rw-r--r-- 1 kenneth _lpoperator 950009856 Jun 20 2018 CentOS-7-x86_64-Minimal-1804.iso -rw-r--r-- 1 kenneth _lpoperator 519045120 Jun 20 2018 CentOS-7-x86_64-NetInstall-1804.iso -rw-rw---- 1 kenneth _lpoperator 7554990080 Mar 28 2020 CentOS-8.1.1911-x86_64-dvd1.iso -rw-r--r-- 1 kenneth _lpoperator 4692365312 Apr 12 2018 Win10_1803_English_x64.iso -rw-r--r-- 1 root wheel 2368405504 Mar 6 2020 Zorin-OS-15.2-Lite-64-bit.iso -rw-r--r-- 1 root _lpoperator 139460608 Jan 29 2021 alpine-standard-3.13.1-x86_64.iso -rw-r--r-- 1 root _lpoperator 36700160 Jun 20 2019 alpine-virt-3.10.0-x86_64.iso -rw-r--r-- 1 root _lpoperator 42991616 Feb 17 2021 alpine-virt-3.13.2-x86_64.iso -rw-rw---- 1 kenneth _lpoperator 3901456384 Sep 13 2019 debian-10.1.0-amd64-DVD-1.iso -rw-r--r-- 1 root _lpoperator 351272960 Feb 8 2020 debian-10.3.0-amd64-netinst.iso -rw-r--r-- 1 kenneth _lpoperator 657457152 Jun 30 2018 debian-9.4.0-amd64-i386-netinst.iso -rw-r--r-- 1 kenneth _lpoperator 305135616 Jun 30 2018 debian-9.4.0-amd64-netinst.iso -rw-r--r-- 1 kenneth _lpoperator 116391936 Dec 29 2019 slackware64-current-mini-install.iso -rw-r--r-- 1 kenneth _lpoperator 322842624 Aug 16 2018 virtio-win-0.1.160-1.iso -rw-r--r-- 1 kenneth _lpoperator 371732480 May 21 2019 virtio-win-0.1.171.iso -rw-rw-rw- 1 kenneth _lpoperator 394303488 Jan 19 2020 virtio-win-0.1.173-2.iso -rw-r--r-- 1 root wheel 412479488 Jul 21 2020 virtio-win-0.1.185.iso drwxrws--- 1 kenneth _lpoperator 4096 Mar 6 2021 virtio-win-0.1.190-1 -rw-rw-rw- 1 root _lpoperator 501745664 Nov 24 2020 virtio-win-0.1.190-1.iso

Haven't used NFS in awhile since I don't have NFS clients locally to the Unraid server anymore But I think it should be like this: 10.0.0.0/24(sec=sys,rw,async,insecure,no_subtree_check,crossmnt) There a few things that depend on your setup. what's the admin user for you in Unraid? the user that's allowed write access to the shares? then you'll add something like anonuid=99,anongid=100,all_squash this will "squash" all access to uid = 99, which is the nobody user in Unraid and group = 100, which is the users group so you can change the uid to match the "admin" user will the clients be accessing the files as root? then add "no_root_squash" to allow root continue access as root

%u is expanded to the username so this tells sshd to look for the private keys in /etc/ssh/root.pubkeys (for the root user)

I think the VNC protocol is limited to 8 character passwords

Could also be some file corruption on your USB stick, where the SSH host keys became 0-byte files or were deleted not copying from /boot during boot is usually an indicator of possible issues with the USB though

Strictly speaking /tmp is not a standalone filesystem - its part of /, but / is also 1/2 total ram by default, unless you adjusted it.

Best solution I can think of that uses base level network devices (ie plain switches and router) Configure eth1 as follows (you can opt not to turn on bridging) Then with the array stopped enable it in docker settings configure the network interface br1 (eth1 if you don't enable bridging) make sure to use the same subnet as your main LAN (where you want Plex to be) ie Subnet is 192.168.50.0/24 Gateway is 192.168.50.1 DHCP pool should be something like 192.168.50.0/24 Ensure the DHCP pool is a range that your DHCP server will never assign (try to prevent collisions now to avoid headaches later on) - again the Docker DHCP pool is not a real DHCP pool and has no connection to the network's actual DHCP server/ nor will it communicate with the network's DHCP server 192.168.50.0/24 is the easiest value to use but if you run any containers on this network, there is a non zero chance of IP address collision if you do not set them up statically use http://jodies.de/ipcalc to compute possible subnets the fit your use case When the docker service is enabled, configure/create your plex dockers with the following info Change the IP to whatever you want it to be This will make your Plex servers accessible at that specified IP address instead of the Unraid IP and as a bonus, all Plex traffic will use that 2nd network connection without sharing with the rest of Unraid.

Docker containers don't actually get their IP from the network DHCP server. the docker engine assigns them in order based on the pool you've set in the network config. Its your job to configure it so that the range will be outside of your DHCP pool (or have a way to ensure they will never conflict) Here's my docker networks (w/VLAN): The network is constrained to get IPs from 192.168.2.128-192.168.2.255 (my DHCP range is outside that range) If you want each container to have a static IP, you can use just set the desired IP in the container settings You can connect as many containers or VMs as you want to the network interface, just take care to avoid dynamic IP assignment collision between the containers and the DHCP server.

Yeah, it seems the headless version is not getting as much love from the team. Have you considered enabling LanSync (I think it is by default), and ensuring the container is on its own IP address (or using host networking). This should help it to sync very fast against your PC (if you have any) However, mine will pickup right away except for some odd corner cases where rebooting Unraid will cause the container to think its on a new PC and require linking again. I don't have a lot of data as I only have a free account, and have moved most of stuff to One Drive, being 1TB storage is part of the family package for Office, and shared files don't eat into your quota unless you make copies of the shared files. I'm still supporting this container, but am considering a different solution using rclone given my current use case.. Sorry I can't be much help.