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