Leaderboard

Well I have and I made the aliases to always use the -g switch too, as I really like to be able to view the progress of those operations. But I left that out of the plugin, so the users can decide for themselves. My aliases from my .bash_profile look like this: alias cp="gcp -g" alias mv="gmv -g" alias n="sudo -u nobody" alias ncp="sudo -u nobody gcp -g" alias nmv="sudo -u nobody gmv -g" The last three allow me to run commands, copy or move files from a root shell as user nobody, which is the default file owner on unRAID. Otherwise the new files will have root as owner, which might cause problems later on.

There have been many posts involving SAS to SATA breakout cables of the Forward vs Reverse types. Which type to use where is generally the question. To make it simple, if the host-controller side is a SAS connector (SFF-8470) and the target side is SATA drives then you must always use a SAS to SATA Forward Breakout Cable. If The Motherboard/host-Controller side are SATA connectors and the backplane is a SAS connector then you must always use a SAS to SATA Reverse Breakout Cable. For SATA to SATA you just use a "SATA" cable as there is only one type, although they do come in different lengths. For SAS to SAS connections there is also just a single cable type. The two breakout cables, forward and reverse, are not the same although they look outwardly to be the same, not withstanding the fact that some of these cables have the SATA portion of the cables at staggered lengths and some have them at fixed length. If you just want to follow the rule you can stop reading now. Why are there two different cable types for SAS to SATA connectivity? An objective of the SATA system design was that SATA cables would have identical connectors at each end, and that SATA devices would have identical connectors independent of whether they were disk drives or disk controllers. This helps to make interconections foolproof and reduces the cost of cables. If you ever look at a SATA to SATA cable they are identical and wired as a 1:1 cable. In a 1:1 cable pin 1 of end-A goes to pin 1 of end-B, pin 2 to pin 2, pin 3 to pin 3, etc. If you were to look at the SATA connector on a host-controller or motherboard and the SATA connector on a disk drive they look the same, and are physically the same, but each are wired differently. A SATA connector has 7 pins. Two of the pins make up the receive pair and two of the pins make up the transmit pair. The other three pins are all used for ground signals. If a 1:1 ("straight-through") SATA to SATA cable is to work, then the receive pair can not be the same pins on each of the two device connectors (Host vs disk)! If they were the same pins then we would need what is generally referred to as a "cross-over" cable. The "Absolute Rule" is that the transmit pins on one side must connect to the receive pins on the other side and vice versa. This is true for PC-PC RS232 connections, Ethernet Connections, SATA connections, and almost all types of serial connections which are duplex, i.e. separate receive and transmit cables. The SATA cable connector design puts the Host/controller side transmit pair on pins 2 & 3, and the Receive pair on pins 5 & 6. On the Disk drive the receive pair are pins 2 & 3, and the transmit pair are pins 5 & 6. As a point of reference pin 7 is the keyed pin. All SAS connectors have their pins structured the same way no matter if they are on a host controller card, or a SAS backplane. Since for each port of the four that make up the SFF-8470 connector the transmit pins and the receive pins are physically in the same location, and we must connect SAS transmit to SATA receive and SAS receive to SATA transmit (for each port); the cables must be different depending on whether the SATA connector is on a disk drive or a Motherboard/Host-Controller. A SAS to SAS cable must therefore be a "cross over" cable to connect the transmit pairs of a port to the receive pairs of the corresponding port on the other side. Hope that helps clear up the mystery.

I believe you can copy the entire contents, just be sure to keep a copy of your license .key file with the licensed stick. It certainly sounds like a reasonable way to accomplish what you need. Make a backup of both USB sticks by clicking on "Flash" on the main GUI tab, then clicking "flash backup". Keep the backup files well identified so you can sort things out later if something goes sideways.

As far as i know you can switch back and forth between all versions (i only go forward tho) Nvm. I also one time was goin back. Works perfect. Back and forth.

This didn't provide enough info on what's connected to what and how. but answer to the question is no.

@murrayrich following you on twitter and I'll post my build later on

Having just considered moving from standard software RAID to unRAID, this is what I would suggest... Assuming that you don't already have an easy to access backup. Get a good deal on a WD 8 or 10TB external drive (Easy Store or My Book). Copy the data to that and verify that it's good. Build your new pool without a parity drive. Copy the data from the external to the new pool, and verify the data. Shuck the 8 or 10TB drive, and install it as your parity drive. Now you have the new pool/system set up, and plenty of room for easy expansion since your parity drive is now much larger. Keep your old 4TB parity drive as a spare in case a drive fails.

Followed on Twitter by @george_danes

I am currently sitting on 296 days and counting on my main machine and my other machine is at 66 days.

HAHAHA I can't believe I left that in there. Originally, I was using /bin/bash -c which resulted in a bashism making the concatenation cause the script in the container to error out with "invalid codec: vp9" even though it was totally valid. Switching for sh -c fixed it but I left my concat workaround in there. Thanks for the fix EDIT: I have moved wget to the HOST side in the latest revision of the script. neither curl or wget is guaranteed to be present inside the docker, since this script was written for unraid, and unraid ships with wget stock - we're using that. I could add a pure bash download function - but that seems unnecessarily complicated.

I submitted the following issue to the github project for this problem. Feel free to comment and add any additional information there. https://github.com/Josh5/unmanic/issues/29

Any update on the official release of 6.7.0 ? or will there be an rc8 ?

since in unraid 6.5.2 we are already at Linux Kernel 4.14, and should include the following patch for TB3 security control: https://lkml.org/lkml/2017/5/26/432 does it mean unraid support eGPU already by: $sudo sh -c 'echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized' like this topic: https://egpu.io/forums/pc-setup/egpu-in-linux-has-anyone-here-gotten-it-to-work/ does anyone ever test it?

I've never done what you're trying to do. I instead use a 4 port nic and send that to pfsense. BUT This is how you change your xml to the the other virtual adapter: click on the red square button on the pfsense vm icon when it is stopped. On the dropdown menu, select edit xml. scroll down to the section that looks similar to this: <interface type='bridge'> <mac address='52:54:00:82:25:11'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> note: your mac address and address will be different. where it lists "model type=" change to <model type='e1000-82545em'/> make sure source birdge is "br0" scroll down further, click save. NOTE: you can no longer edit your vm using the vm manager as custom edits will then be discarded and you will lose the e1000. Don't be surprised that when you attempt to boot the server, and it is looking for the pfsense vm for network connectivity, that it can take a while. Docker runs an update check at boot. And if there is no network detected, each docker has to go through a preset timeout which is somewhere between 100 and 300 seconds if I remember correctly. This is on every autostart docker in order. This is before the vm's are autostarted. PRO TIP: set your unRaid server on a static ip. it's easier to find it after setting up pfsense and running the firewall on the same box. Good luck.

I have one NIC pass through to pfsense for WAN and I set the unraid created bridge as LAN. I had to modify the bridge in pfsense VM xml to display the Bridge as an e1000 Ethernet adapter instead of the default virtio adapter that unraid assigns. Unraid gets its IP from the bridge and the physical NIC feeds my switch for other devices in my LAN. Hope that made sense. Sent from my iPad using Tapatalk