something fishy

It doesn't have files on the array according to the "compute" button in the shares tab and verified with Midnight Commander. I used to have some orphan appdata files and I forced them off under 6.10.2. As I've said, all was normal with the cache directories plugin operating in 6.10.2 and all seems normal in 6.10.3 without the plugin. Thanks

This is for me? Yes I'm sure. Appdata is cache only and my sageTV recording directory is on a pool drive not on the array. These shares were excluded from cache directories and were working as expected in 6.10.3: asleep when not used. With the plug in removed, expected behaviour has returned to all disks. The only disks spun up are those that have current file activity. For eg, at time of writing I have a scheduled windows disk image running so one array drive and parity are spun up, plus cache (an SSD). The remaining 6 array drives are asleep. SageTV has just started recording so its dedicated pool drive spun up around 3 minutes ago. Thanks

I appreciate that. Thank you. I've removed for the moment. It was working as designed on 6.10.2 (no impact on disk sleep that I could see or any other negative side effects) and with the same settings carried over appeared not to work as designed on 6.10.3.

Removing Dynamix cache directories and rebooting appears to have sorted it. Smart requests in the log no longer spin up the disk and unused disks spin down on schedule. Thanks, this is mostly static, infrequently accessed data so spindown is important on heat and power grounds. Cheers Eric

Is there reason that array disks won't spin down after this upgrade. After upgrade (smooth, no problems) to 6.10.3 all but one of my array disks are staying spinning with no file access. If i spin the array down manually (using the little down arrow button under the disk listing) they almost immediately spin up in response to a smart request. This is copy and past from the live log: Jun 17 15:03:43 shortie emhttpd: spinning down /dev/sdj Jun 17 15:03:43 shortie emhttpd: spinning down /dev/sdk Jun 17 15:03:44 shortie emhttpd: spinning down /dev/sdh Jun 17 15:03:45 shortie emhttpd: spinning down /dev/sdi Jun 17 15:03:46 shortie emhttpd: spinning down /dev/sdf Jun 17 15:03:46 shortie emhttpd: spinning down /dev/sdg Jun 17 15:03:47 shortie emhttpd: spinning down /dev/sdd Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdj Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdg Jun 17 15:03:49 shortie emhttpd: read SMART /dev/sdf Jun 17 15:03:58 shortie emhttpd: read SMART /dev/sdk Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdh Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdd Jun 17 15:04:08 shortie emhttpd: read SMART /dev/sdi With 6.10.2 the array was spun down as expected. I have Dynamix cache directories installed and one disk is reporting as over temperature (server in marginally cooled location and its hot, ironically, because the array is spun up). Thanks Eric

I bought an old QNAP 1079 Pro on ebay https://www.qnap.com/en-uk/product/ts-1079 pro for the express purpose of running unraid. It was the cheapest way that I could get a compact 10 bay hotswap enclosure. Its serving well and appears to have great cooling. I doubt that I could have built better for twice the second hand price I paid. This is an i3 machine and mine came with 16Gb of RAM. It has 2x onboard NICs and mine came with an extra dual NIC card (removed see below). A few observations - I had to load the QNAP OS and switch off "environmental energy management" (or something like that) to enable boot on power restore (for a UPS). The setting is not exposed in the BIOS. Power cycle it a few times to make sure its working - sometimes the setting did not stick for me. This was maybe a flat cmos battery - To change the cmos battery requires the mainboard being removed. This needs six screws removing (4x ordinary and both the locking screws on the vga port) the SATA backplane removing (do this without disks present!) and pretty much all mainboard cables pulling. It's not hard but it is very fiddly and the chassis edges are sharp. - I couldn't get the front LED working either, I unplugged it. - CPU cooling looked marginal to me (slowing the case fans down caused a kernel panic before HDD temps became a problem). I wedged a noctua fan on top of the CPU heatsink (there are spare fan headers). Switch the fan control for the case fans to fixed speed in the BIOS and Dynamix fan control plugin seems to work. - I stuck a cheap sata card into the spare pcie slot (designed for a second NIC card) for a SSD cache drive. A 2.5 inch HDD/SSD can sit loose above the drive bay (where the PSU lives). You will need a special card backplate (one came with the NAS in my case) as standard low profile backplates don't work. This done all ten drive bays are free for the array. - I'm only using one of its two onboard NICs but as far as I can tell unraid is perfectly happy in this hardware and I can see no reason why it wouldn't work - Started off by pulling the QNAP DOM module. But there is a second on board USB header (presumably for a redundant DOM?) and I fashioned a short flying lead so that my unraid flash drive is stored internally (attached to the base of the case behind the drive bay). Just select the correct boot order in the BIOS. - It seems to reboot once during a start up sequence for reasons I don't understand. But I think using the QNAP OS it does this several times. The unraid webui is available about 90 seconds after boot which is 3-4 minutes quicker than the QNAP web UI. - Its as quiet as the N54L HP microserver that preceded it. The HDDs seem happier spinning down than they did in the microserver. The unraid system info reports the NAS as: Model: N/A M/B: ICP/iEi QA61 Version V1.0 - s/n: To be filled by O.E.M. BIOS: American Megatrends Inc. Version 4.6.4. Dated: 01/19/2012 CPU: Intel® Core™ i3-2120 CPU @ 3.30GHz HVM: Not Available IOMMU: Not Available Cache: 128 KiB, 512 KiB, 3 MB Memory: 16 GiB DDR3 Multi-bit ECC (max. installable capacity 32 GiB) Network: eth0: 1000 Mbps, full duplex, mtu 1500 eth1: interface down Kernel: Linux 5.10.28-Unraid x86_64 OpenSSL: 1.1.1j Uptime: 0 days, 04:09:09

@prostuff 2) My flexget log has started reporting these errors again 2013-07-06 16:30 WARNING cron_env Your cron environment has different filesystem encoding (ANSI_X3.4-1968) compared to your terminal environment (UTF-. 2013-07-06 16:30 WARNING cron_env Your current cron environment results filesystem encoding ANSI_X3.4-1968 which supports only ASCII letters in filenames. I don't think that these errors have any real significance. I ran with them for years. They are however irritating and they sure fill up a flexget logfile. The only way to get rid of them in my case was to have cron call a script that sets the environment variable rather than running flexget directly: #!/bin/bash export LANG=en_US.UTF-8 flexget -c /mnt/user/transmission/flexget/shows.yml --cron seems to work in my (non unmenu package) flexget install.

running flexget from a script that sets the environment variable does the trick, heres mine: #!/bin/bash export LANG=en_US.UTF-8 flexget -c /mnt/user/transmission/flexget/shows.yml --cron

Thanks, I did a couple of long smart tests and the results looked identical to me. I've swapped out the drive (for a Toshiba 3Tb equivalent) and the array is fault tolerant again. Am now preclearing a second new 3Tb disk to keep in a box as a spare and the original is on a 4x preclear stress test in my backup server. As an aside I'm noticing how much quicker the new 1Tb platter drives at sequental reads and writes are than my Hitachi 7K3000s; its really visible on the preclears which I started about the same time. What is ioctl error? google doesn't seem to help much. Eric

Hi I had a drive redballed yesterday. The syslog contains the following lines (the redballed drive is sdb): Mar 18 15:51:41 shortie kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 18 15:51:41 shortie kernel: ata2.00: failed command: READ DMA EXT Mar 18 15:51:41 shortie kernel: ata2.00: cmd 25/00:c0:c8:e7:f3/00:00:5a:01:00/e0 tag 0 dma 98304 in Mar 18 15:51:41 shortie kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Mar 18 15:51:41 shortie kernel: ata2.00: status: { DRDY } Mar 18 15:51:41 shortie kernel: ata2: hard resetting link Mar 18 15:51:51 shortie kernel: ata2: softreset failed (device not ready) Mar 18 15:51:51 shortie kernel: ata2: hard resetting link Mar 18 15:52:01 shortie kernel: ata2: softreset failed (device not ready) Mar 18 15:52:01 shortie kernel: ata2: hard resetting link Mar 18 15:52:12 shortie kernel: ata2: link is slow to respond, please be patient (ready=0) Mar 18 15:52:36 shortie kernel: ata2: softreset failed (device not ready) Mar 18 15:52:36 shortie kernel: ata2: limiting SATA link speed to 1.5 Gbps Mar 18 15:52:36 shortie kernel: ata2: hard resetting link Mar 18 15:52:41 shortie kernel: ata2: softreset failed (device not ready) Mar 18 15:52:41 shortie kernel: ata2: reset failed, giving up Mar 18 15:52:41 shortie kernel: ata2.00: disabled Mar 18 15:52:41 shortie kernel: ata2.00: device reported invalid CHS sector 0 Mar 18 15:52:41 shortie kernel: ata2: EH complete Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Unhandled error code Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] CDB: cdb[0]=0x88: 88 00 00 00 00 01 5a f3 e7 c8 00 00 00 c0 00 00 Mar 18 15:52:41 shortie kernel: end_request: I/O error, dev sdb, sector 5820901320 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Unhandled error code Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] CDB: cdb[0]=0x88: 88 00 00 00 00 01 5a f3 e8 88 00 00 00 48 00 00 Mar 18 15:52:41 shortie kernel: end_request: I/O error, dev sdb, sector 5820901512 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Unhandled error code Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] CDB: cdb[0]=0x8a: 8a 00 00 00 00 01 5a f3 e7 b8 00 00 00 10 00 00 Mar 18 15:52:41 shortie kernel: end_request: I/O error, dev sdb, sector 5820901304 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901256/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901264/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901272/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901280/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901288/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901296/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901304/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901312/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901320/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901328/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901336/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901344/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901352/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901360/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901368/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901376/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901384/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901392/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901400/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901408/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901416/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901424/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901432/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901440/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901448/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901456/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901464/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901472/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901480/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901488/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901496/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901504/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 read error Mar 18 15:52:41 shortie kernel: handle_stripe read error: 5820901512/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901240/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901248/1, count: 1 Mar 18 15:52:41 shortie kernel: md: recovery thread woken up ... Mar 18 15:52:41 shortie kernel: md: recovery thread has nothing to resync Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Unhandled error code Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 Mar 18 15:52:41 shortie kernel: sd 1:0:0:0: [sdb] CDB: cdb[0]=0x8a: 8a 00 00 00 00 01 5a f3 e7 c8 00 00 01 08 00 00 Mar 18 15:52:41 shortie kernel: end_request: I/O error, dev sdb, sector 5820901320 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901256/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901264/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901272/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901280/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901288/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901296/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901304/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901312/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901320/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901328/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901336/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901344/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901352/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901360/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901368/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901376/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901384/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901392/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901400/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901408/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901416/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901424/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901432/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901440/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901448/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901456/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901464/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901472/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901480/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901488/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901496/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901504/1, count: 1 Mar 18 15:52:41 shortie kernel: md: disk1 write error Mar 18 15:52:41 shortie kernel: handle_stripe write error: 5820901512/1, count: 1 When I tried to run a smart test on the drive it failed with ioctl error: -5 A clean powerdown, a quick reseat of the drives and the drive is accessable but obviously still redballed. The smart results look clean to me (but I'm a rookie): ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 135 135 054 Pre-fail Offline - 86 3 Spin_Up_Time 0x0007 126 126 024 Pre-fail Always - 615 (Average 615) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 967 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 135 135 020 Pre-fail Offline - 26 9 Power_On_Hours 0x0012 098 098 000 Old_age Always - 14099 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 63 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1085 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 1085 194 Temperature_Celsius 0x0002 176 176 000 Old_age Always - 34 (Min/Max 22/47) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 I've bought a couple of replacement drives (one to rebuild onto tonite; one to preclear and keep as a hotswap). I'll obviously stress test the the redballed drive when the array is protected again but given the above is this likely a drive issue or a problem with the PC/controller? The server is built in a HP proliant microserver (36L) disks are Hitachi 7K3000s. Unraid is 5.0 beta 8. Full syslog attached as zipfile. Thanks Eric syslog-20130318-203007.zip

So the conclusion is either that I need implicitly to trust the VPN service that I am using (for example when I securely connect to my office network from remote locations) or put a firewall between my end of the VPN tunnel and my home network.

Interesting that you say this as it accords with my worries. Some specifics. I am testing a VPN provided by a company called seed.st (which is known for providing seedboxes). It claims to offer a switchable firewall (in which I can select open ports) however I do not think this works. I have a support request lodged with them concerning this, I'd like to investigate the general principles here. As it stands today if I initiate an VPN connection with Seed.st (openVPN) from my laptop and open up the deluge bittorrent client *any* arbitrarily selected port reports that its open to incoming traffic. I can confirm this with GRC's shields up. If this is the case how is it different from the PC being placed in the DMZ in my router's firewall? And if it is the same as putting the PC in the DMZ what would stop someone telnetting into my unraid server, via the VPN's endpoint IP address (until this issue is resolved my unraid server is not using VPN, theres no way that I would put an unraid server in a DMZ). I should observe that I don't think that Seed.st is typical here. I also have a vpn account with a "normal" VPN provider (Overplay.net) and repeating the above does not show ports to be open (nor does it have a firewall setup page). However given the increased popularity of ISPs restricting P2P traffic and the option of using VPN to avoid this I would like to understand the risks. Until I had actually started to try and get a "port open" connection I hadn't even considered a VPN as a source of risk.

Excuse me if this is a question that reveals ignorance of how VPNs work. I am considering using a VPN to avoid traffic shaping of bittorrent traffic from my ISP (using the openvpn unraid plugin). I have found a VPN provider that appears to forward all ports I need (apologies if wrong terminology, what I mean is that torrent clients report that they are able to receive incoming connections on a reasonable number of arbitrarily selected ports). However I am worried that this will leave unraid vulnerable to attack in a similar way to if it were in a DMZ. Are my fears justified and is there anything I can do about it? Thanks Eric

Apologies for bumping, but does anyone have any ideas. The issue is recognised by flexget's developers http://flexget.com/ticket/801# but the workarounds suggested aren't working for me. I've tried: */<whatever> * * * * cd ~/flexget/ && /usr/bin/env LANG="en_CA.utf8" ./bin/flexget --cron (with appropriate paths) but I get an error in the syslog at boot for this line and the cron job doesn't run so I presume that Unraid's cron doesn't like the syntax. I've also tried calling a script from cron that sets the environment variable LANG=en_US.utf8 That seems to work sometimes but not all. Any help would be gratefully received. This is using 5.0 rc4 Cheers Eric

Running flexget (1.0r3016) I get these lines in my flexget.log file: 2012-07-08 18:20 WARNING cron_env Your cron environment has different filesystem encoding (ANSI_X3.4-1968) compared to your terminal environment (UTF-. 2012-07-08 18:20 WARNING cron_env Your current cron environment results filesystem encoding ANSI_X3.4-1968 which supports only ASCII letters in filenames. I'm a linux noob and nothing I've found online seems to work. Can someone point me in the right direction to change the crontab environment variables in unraid please. Cheers Eric

@Prostuff1 Thanks for this, I cobbled together a flexget install myself which I am still using at this point but I do depend on your Transmission package, so thanks for all your hard work. You note: ? I'm running flexget 1.02r2776 on the Python 2.6.4 that is in unmenu. Operationally its fine with the exception that I get This error: http://flexget.com/ticket/801# and the solutions posted sometimes appear to solve the problem, sometimes not. Flexget still works so I ignore and just accept that it makes for a bigger logfile. And this error (from the log file:) 2012-03-10 14:20 INFO rss thebox Invalid XML received (line 2:-1: Document is empty ). However feedparser still produced entries. Ignoring the error... Which I attribute to the tracker not flexget. Again it makes for a bigger log file but flexget still works so I ignore.

@naxiand I replied to you with the steps that I took to install flexget on the N40L versus custom build thread. It was done from memory so apologies in advance if I missed something out but it should give you a starting point. Sorry I'm not skilled enough with linux to automate the install procedure in any way. Cheers Eric

One more point for the microserver. You can install a remote access card if you want to run it headless. Details are http://www.livingonthecloud.net/2011/08/hp-microserver-remote-access-card.html Cheers Eric

@naxiand I keep meaning to set it down on paper but haven't got around to it yet, sorry. Stupidly I didn't make explicit step by step instructions when I did it and I haven't had the chance to do a repeat install on my backup server. However I do recall a few general points 1) I just installed java from unmenu; set to install every boot. 2) I then downloaded and installed easy_install as per the instructions here http://pypi.python.org/pypi/setuptools 3) add the equivalent line in the go script to replicate on every boot 4) Download the flexget program to a directory you've created on your flash drive using the instructions on this page http://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines (search the page for install in un-networked machines). 5) Test install flexget at the command prompt, again its on http://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines (look for "install in un-networked machines") and then add this line also to your go script to install at every boot. 6) Download the transmission rpc libary as per described in http://flexget.com/wiki/Plugins/transmission using the same process for un-networked machines as above 7) test load at the command prompt and add the line in the go script that so that this install at every boot also 8.) Reboot to make sure that everything is installing as you think it should. 9) test using flexget -V in a putty session 10) create a configuration file (*.yml). My recommendation is to put this on a HDD (flexget writes its log to the same directory) and specify it explictly with flexget -c /path/to/config.yml 11) when you're sure its running fine schedule with cron (the flexget website has examples). Sorry if I've missed stages out, this is from memory but the install instructions on the flexget website (for Linux/BSD) are very good. Thye're what I started with and I have zero linux experience so I just carried out each step, reflected in the go script so that it would repeat at boot up and then tested before moving to the next step. You can follow the flexget instructions verbatim if you don't mind having the go script access the internet and download new versions of flexget and transmissionrpc every boot. If you don't want this then the instructions above remove the need by adding a little more initial setup complexity. BTW the flexget configuraton file is IMO a pain, edit it using a programmers text editor with display whitespace turned on and never use tabs. Plus always test, nearly all errors in a config file will stop flexget from downloading anything not just the line where the error is made.

The LIAN LI case is nice and will hold more HDDs, seven if you repurpose the ODD at the top. However faced with the same sort of question I went with the HP's predecessor the N36L. I was motivated by 1) I like the design - 4 externally accessable HDDs plus the ODD that can be repurposed with a hot swap drive bay. 2) I like the fact that it has an internal USB drive expressly designed for an OS to boot off. 3) Its quiet out of the box (theres a review on SPCR that tells you how to use a lower noise fan, but I couldn't be bothered, stock its in the ambient noise of my office). 4) Its very low power consumption. 5) I could get one very cheap (60% of component cost of building an equivalent) 6) There is a lot of discussion on various message boards about unraid and freenas that gave me confidence the HP would work. In fact I have only good things to say about the HP. It does work out the box with unraid (almost, if its like the N36L you should flash it with the "russian bios" to enable AHCI on the ODD connector) and I get preclear/parity check/transfer rates that seem better than most acheive in unRaid using other hardware. Also WOL appears to work fine. I run unraid 5.14, plus unmenu with transmission and flexget and have never had any problems. I would do it again (in fact I have, a second that I use as a backup server - it backs up the main server once a month) however if I'm honest I would have been happier still if it offered another couple of disk slots as this would give me the option of using a cache drive and fully using my Unraid plus licenses. I don't need either of these, I use 5x 3Tb HDDs and they give me enough speed and storage even with Transmission writing to one of the array drives but if the option is there... The proliant was the first PC in a long time that I haven't built and to be honest I found it quite nice not having to bother.

User of 5.12a with no problems since launch on a N36L Proliant Microserver. Backing up my desktop PC to the unraid slowed down however and I noticed these error lines in the syslog. The speed subsequently increased again. Nov 24 20:37:40 shortie kernel: [<c105f857>] warn_alloc_failed+0xb2/0xc4 Nov 24 20:37:40 shortie kernel: [<c105ffc2>] __alloc_pages_nodemask+0x456/0x47f Nov 24 20:37:40 shortie kernel: [<c128fb68>] ? skb_copy+0x2e/0x83 Nov 24 20:37:40 shortie kernel: [<c106003f>] __get_free_pages+0xf/0x21 Nov 24 20:37:40 shortie kernel: [<c107e11a>] __kmalloc_track_caller+0x2c/0xee Nov 24 20:37:40 shortie kernel: [<c128f0ee>] __alloc_skb+0x53/0xf1 Nov 24 20:37:40 shortie kernel: [<c128fb68>] skb_copy+0x2e/0x83 Nov 24 20:37:40 shortie kernel: [<f84463af>] tigon3_dma_hwbug_workaround+0x36/0x1b1 [tg3] Nov 24 20:37:40 shortie kernel: [<f8446bed>] tg3_start_xmit+0x6c3/0x7a8 [tg3] Nov 24 20:37:40 shortie kernel: [<c1295bad>] dev_hard_start_xmit+0x245/0x31c Nov 24 20:37:40 shortie kernel: [<c12a4466>] sch_direct_xmit+0x50/0x137 Nov 24 20:37:40 shortie kernel: [<c1295d82>] dev_queue_xmit+0xfe/0x274 Nov 24 20:37:40 shortie kernel: [<c12b0127>] ip_finish_output+0x227/0x262 Nov 24 20:37:40 shortie kernel: [<c12b01c6>] ip_output+0x64/0x68 Nov 24 20:37:40 shortie kernel: [<c12adf4d>] ip_local_out+0x57/0x5b Nov 24 20:37:40 shortie kernel: [<c12afb5a>] ip_queue_xmit+0x2a5/0x2f2 Nov 24 20:37:40 shortie kernel: [<c12beee8>] tcp_transmit_skb+0x4d7/0x50d Nov 24 20:37:40 shortie kernel: [<c12c11f7>] tcp_write_xmit+0x2f9/0x3d7 Nov 24 20:37:40 shortie kernel: [<c12c1319>] __tcp_push_pending_frames+0x18/0x6f Nov 24 20:37:40 shortie kernel: [<c12bdfc9>] tcp_rcv_established+0x501/0x578 Nov 24 20:37:40 shortie kernel: [<c12c33b5>] tcp_v4_do_rcv+0x46/0x137 Nov 24 20:37:40 shortie kernel: [<c12c386c>] tcp_v4_rcv+0x3c6/0x647 Nov 24 20:37:40 shortie kernel: [<f847935b>] ? ahci_qc_prep+0xb3/0x126 [libahci] Nov 24 20:37:40 shortie kernel: [<c12ac081>] ip_local_deliver_finish+0x93/0x158 Nov 24 20:37:40 shortie kernel: [<c12ac172>] ip_local_deliver+0x2c/0x2f Nov 24 20:37:40 shortie kernel: [<c12abd8b>] ip_rcv_finish+0x263/0x28b Nov 24 20:37:40 shortie kernel: [<c12abfbb>] ip_rcv+0x208/0x23b Nov 24 20:37:40 shortie kernel: [<c1293604>] __netif_receive_skb+0x234/0x25a Nov 24 20:37:40 shortie kernel: [<c1294a5f>] netif_receive_skb+0x5d/0x63 Nov 24 20:37:40 shortie kernel: [<c1294b1c>] napi_skb_finish+0x1e/0x34 Nov 24 20:37:40 shortie kernel: [<c1294f4c>] napi_gro_receive+0xc7/0xcf Nov 24 20:37:40 shortie kernel: [<f84484bf>] tg3_rx+0x3f6/0x548 [tg3] Nov 24 20:37:40 shortie kernel: [<f8448668>] tg3_poll_work+0x57/0x112 [tg3] Nov 24 20:37:40 shortie kernel: [<c1003bb6>] ? handle_irq+0xd/0x6a Nov 24 20:37:40 shortie kernel: [<f844887f>] tg3_poll+0xae/0x1d8 [tg3] Nov 24 20:37:40 shortie kernel: [<c1295022>] net_rx_action+0x59/0x12a Nov 24 20:37:40 shortie kernel: [<c102ccce>] __do_softirq+0x6b/0xe5 Nov 24 20:37:40 shortie kernel: [<c102cc63>] ? irq_enter+0x3c/0x3c Nov 24 20:37:40 shortie kernel: <IRQ> [<c102cb21>] ? irq_exit+0x32/0x53 Nov 24 20:37:40 shortie kernel: [<c100360b>] ? do_IRQ+0x7c/0x90 Nov 24 20:37:40 shortie kernel: [<c130b8a9>] ? common_interrupt+0x29/0x30 Nov 24 20:37:40 shortie kernel: [<c1007e14>] ? default_idle+0x2e/0x43 Nov 24 20:37:40 shortie kernel: [<c1007f3f>] ? amd_e400_idle+0xb1/0xcb Nov 24 20:37:40 shortie kernel: [<c1001a60>] ? cpu_idle+0x3a/0x52 Nov 24 20:37:40 shortie kernel: [<c1306753>] ? start_secondary+0xad/0xaf I don't know if they're relevant but posting here anyway. Full syslog attached. The error occurs a few times. Cheers Eric syslog-2011-11-251.txt

@prostuff1 Keeping the older .conf file available would certainly be enough in my opinion. Also I presume that at some point this package will be fully rolled into unmenu and become available in a default unmenu install. If so it might be useful to note somewhere in the package description what version of Transmission is installed and where to get an earlier .conf file if a different version is needed. I'm voicing this because some private trackers are very picky (and seemingly arbitrary) about client versions and many/most are now closed to general admission so we all run scared from the mods... Again thanks for doing this at all. Cheers Eric

First of all thankyou for your work on this. Its excellent. Could I make a feature request? Would it be feasible to allow a choice of Transmission version at install. Those of us that use private trackers are often restricted in which version that we can use (with it typically not being the latest release). For example the current 2.33 works for me, but I will have to pass if you roll Transmission 2.41 into the next version of the package. I know some trackers are still down at 2.01 for the latest approved version(!) Most of don't have the linux knowledge necessary to downgrade program versions in a way in which we can for windows so we live in fear of a bugfix or enhancement moving transmission onto a version not approved (or worse explicitly disallowed) on our tracker of choice. Cheers Eric

Having been a Deluge user for a long while because it offered full remote administration and integration with Flexget I am a very happy user of Transmission on unraid (first the BubbaQ version, now the Prostuff1 version), also well integrated with flexget and with the Transmission remote GUI (google for it) completely controllable from a remote PC/Mac/linux box. It's not the answer to your question but unless your tracker absolutely requires Deluge I'd give it a look.

I'm keen to try this out. However I get a 403: Forbidden error: when unmenu tries to download the tgz file (file is zero byte size). Do I need to do anything special to access the file (other packages seem to download OK) Thanks Eric