ken-ji

doing a tar to tar might work better, particularly no time will be wasted with compression. tar -C /mnt/disk1/path1 -cf - * | tar -C /mnt/disk2/path2 -xvf -

surefire way to reset your changes is to restart the server. unRaid lives on a ramdisk and unless you've been adding/running stuff to copy the config changes back to the correct places in the flash drive, the reboot will give you unRaid before you made manual changes to the configs (WebUI changes not withstanding) normal ways of restrict root login via ssh is to: * disallow via permitrootlogin=no in /etc/ssh/sshd_config and having normal users login. (but normal users normally don't exist in unraid) * disallow ssh password logins and require key files or certificates to login ( doable ) * ip whitelisting via iptables (I really don't advise this) * ip whitelisting via the router (still a rather difficult way) Still, it is not recommended to allow the internet to access to your unraid (at least not directly over ssh or webui). if you must, use a inbound VPN. Me, I have a private VPN with a VPS, and my VPS will only accent key logins over ssh. From there I can login to my unRaid server as if i was local

I'm sorry if I misunderstand you. unRaid doesn't have normal users which can be allowed to login (unless you really hack up the system) thus only root can login via ssh. From the remote side, this is a security risk as you will certainly get hacked in a matter of time. So the only real way to prevent root from login remotely is to prevent remote logins. So, again, please do not port forward ssh (port 22). You can still login locally (ssh <unraid ip>). and no body can attempt to login from the internet.

Don't forward port 22 on the unraid server. UnRaid does not have local users that can login via ssh.

My bad - nc (netcat) is in an additional slackware package nc-1.10-x86_64-1.txz (I think nerdtools has this) in any case scp is as simple as scp <localfile> root@<unraid>:/mnt/cache/<somedir> or scp <localfile> root@<unraid>:/mnt/user/<somedir> for single file copies and scp -r <localdir> root@<unraid>:/mnt/cache/<somedir> or scp -r <localdir> root@<unraid>:/mnt/cache/<somedir> for directory copies ( -r being recursive )

In your current config I don't see anything that could be broken. oh well.

Most DHCP servers and clients are not configured to assign two or more subnets to a single host without colliding on the default route. (And I just noticed the diagnostics didn't include networking stuff like routing table) While the server is in the normal network location/connection run the following commands and post them back ip addr ip route I'm guessing your default route is wrong or clobbered.

Well the "have X devices" could also click to open an info box with all the devices that would be counted against your license, so no surprises there.

How fast does plain scp run for you? rsync can be very slow (depending on the flags used) because it might be asking the unraid server to supply the source files for comparison before it sends the deltas. Try running this: #unRaid nc -v -l -n 2000 >/dev/null #Fedora dd if=/dev/zero bs=1000M count=10 | nc -v -v -n <<unraid hostname/ip>> 2000 10485760000 bytes (10 GB) copied, 18.2118 s, 576 MB/s then try again, changing the unRaid one to: nc -v -l -n 2000 > /mnt/cache/dummyfile This will send 10GB down the wire from the Fedora server to the unRaid server (RAM in #1; cache SSD in #2) and you'll get a how fast after.

Don't bother stopping the rebuild. Stop docker You can just delete the contents of the appdata share You can do the same for all the shares if you want and nuke the shares to reset everything. Normally the tools | new config is used to do a reset of the array, while simply formatting the usb drive and reinstalling does most of the work. but you definitely need to delete the dockers.img to clear out the docker images. <I've never had to start over so I'm not sure - Hopefully somebody else can point you the way>

I'd recommend a full redo since its kinda obvious a number of your config files/ etc stuff stored on the old USB is kinda not there. The dockers get preserved somewhat since they are on the cache drive, which seems to have survived intact. I don't remember where the now missing icons are stored though. If you copied the shares dir over, the share definitions are mainly preserved, but not necessarily the details which would be inside the share cfg files. Suggest you disable dockers under Settings|Dockers, delete the docker.img file and start over.

You are running a trial - I'm fairly sure you can ignore the Trial.key file and apply for a new trial on the new usb flash drive. I'm sure something is wrong if the WebUI is not accessible, but you can still ssh in.

looks like your flash drive is either full or still has some issues. Try using a different flash drive. If tower.local does not resolve. access the web ui using IP address.

Actually, your current diagnostics show that its in Trial mode. Hence my initial reply: Since the cfg file for the shares are present, your shares should be available right away, once the OS is registered (either as a Trial or with your original key) and array is started. So locate your original key (Plus.key or Pro.key file) and copy it into the config directory of the flash drive.

I'm only guessing here, but that error message indicates a version mismatch, between sshd and the open ssl library. This most likely means one of your plugins is not compatible with the 6.2 series - possibly the putty package?

The /rpc location is odd. I understand that the web and rpc endpoints are both under /transmission/ ie http://transmissionip:9091/transmission/web and http://transmissionip:9091/transmission/rpc Thus mine is like this location /transmission { satisfy any; allow 192.168.2.0/24; auth_basic "Transmission Remote Web Client"; auth_basic_user_file /config/transmission.passwd; proxy_pass http://192.168.2.5:9091; access_log off; } With the bonus of allowing my LAN to access transmission without needing a password. (All of this is under HTTPS block)

You should be able to edit the wiki yourself. Righty, patched it in. Unfortunately so... but I though about it before I started and decided that fitting a minimum 8 drive tower in the book shelf (shelf wasn't deep enough) was asking for a lot of pain and decided to go with a mini-itx build with external 8 bay tower and still have room to expand on.

I guess I should ask to have my SAS/SATA card added as a data point: LSI-9206-16e this is a PCI3.0 x8 lane card with 4x external SFF8644 connectors allowing for connection to 16x direct attached drives or 1024 multiple expander attached drives. As for the external enclosure, I'm currently using this with a ARECA ARC-4036 8 drive enclosure with built-in expander. I'm using all this with a ITX motherboard and case, thus minimizing the the issues with PSU needing to support high power ratings or any rail issues.

Upgraded from 6.2.1 - no visible issues. (knock on wood)

Yes FTTH is available now. my parents have it. my brother has it. I don't. :'( I'm current paying a bit for 5Mbps... with no possible upgrade in sight. and Other options want a bloody 12mo lock-in minimum. - my DSL line seems to cap out at 6.5Mbps...

The fixed error on your USB flash drive might have caused a bunch of config files to become lost, which would explain the ssh and drive assignment issues. You might need to set it up from scratch and copy in the missing key file from your email.

Just delete the whole lines. 192.168.1.252 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNaagRAOo0jvQBgraRps6D1BVjrsdhbqA3yh/FmtMAShVqKdoibxgq7sawaSGJYdoyvQ8kFc8qSDO7pbdC6c1bA= tower.local ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNaagRAOo0jvQBgraRps6D1BVjrsdhbqA3yh/FmtMAShVqKdoibxgq7sawaSGJYdoyvQ8kFc8qSDO7pbdC6c1bA= Sorry, there are no issues with line endings as you are using a Mac. (that's a corss Windows/Linux issue)

Likely, some of the ssh host key files in your /boot/config/ssh folder got corrupted/erased and thus unraid regenerated those files, hence the error about the changed host key. Just clean up the file (line 4, and maintain the line endings) /Users/Vurtopia/.ssh/known_hosts on you Mac.

As somebody with a hot swap cage, some work needs be done by the user to properly detect new drives (or removed drives) echo "- - -" > /sys/class/scsi_host/host0/scan host0 kinda depends on your system though (its probably host0 or host1) you'll notice that your scsi devices list list the drives without the /dev/sdX names, meaning linux is not aware they exist. until linux is aware, restarting the array is not going to work.

I'm running an ELK stack on port 514 (tcp and udp) and have unRaid forwarding to it via the following code in my go file (which i'll migrate to the users scripts when I get around to it) # Log to ELK echo "*.* @@192.168.2.5:514" >> /etc/rsyslog.conf /etc/rc.d/rc.rsyslogd restart (192.168.2.5 being the ip of my unraid)