chuck23322

You probably want the "preclear.sh results" thread. https://forums.lime-technology.com/topic/3930-preclearsh-results-questions-about-your-results-post-them-here/

Looks good. In the past, the errors immediately began (whether or not I actually used the plugin). I'm assuming it was something related to my old motherboard having a floppy-chip and returning a null serial (at least that''s what I gathered from the above) I checked my NewEgg order history -- that MoBo dates back to a 2010 order when I first built a WHS server -- but quickly converted it to an Unraid server with 250 & 500mb drives -- back then, on 4.x unraid Highly doubt any MoBo of recent still has a floppy controller. Anyway, huge thanks. Sincerely appreciate having a GUI front-end to preclear...

No, I don't. But was looking at syslog, and apparently Unraid thinks I do root@unraid:~# cat /var/log/syslog | grep fd0 Sep 24 09:11:03 unraid kernel: pci 0000:00:11.0: reg 0x18: [io 0xfd00-0xfd07] Sep 24 09:11:03 unraid kernel: Floppy drive(s): fd0 is 1.44M Sep 24 09:11:29 unraid kernel: blk_update_request: I/O error, dev fd0, sector 0 Sep 24 09:13:41 unraid kernel: blk_update_request: I/O error, dev fd0, sector 0 Sep 24 09:15:02 unraid kernel: blk_update_request: I/O error, dev fd0, sector 0 root@unraid:~# Digging further -- checking my motherboard specs - https://www.gigabyte.com/Motherboard/GA-MA770T-UD3-rev-14#sp South Bridge: 1 x IDE connector supporting ATA-133/100/66/33 and up to 2 IDE devices 6 x SATA 3Gb/s connectors supporting up to 6 SATA 3Gb/s devices Support for SATA RAID 0, RAID 1 and RAID 0+1 iTE IT8720 chip: 1 x floppy disk drive connector supporting up to 1 floppy disk drive

Hi, I'm at Unraid 6.3.5 root@unraid:~# lsblk --version && lsblk -nbP -o name,type,serial lsblk from util-linux 2.28.2 NAME="md11" TYPE="md" SERIAL="" NAME="sdf" TYPE="disk" SERIAL="K4K7UXVB" NAME="sdf1" TYPE="part" SERIAL="" NAME="md8" TYPE="md" SERIAL="" NAME="sdo" TYPE="disk" SERIAL="5XW1BMCH" NAME="sdo1" TYPE="part" SERIAL="" NAME="sdd" TYPE="disk" SERIAL="WD-WMAZA5166243" NAME="sdd1" TYPE="part" SERIAL="" NAME="md6" TYPE="md" SERIAL="" NAME="sdm" TYPE="disk" SERIAL="K4KA796B" NAME="sdm1" TYPE="part" SERIAL="" NAME="sdb" TYPE="disk" SERIAL="5YD3YW18" NAME="sdb1" TYPE="part" SERIAL="" NAME="md4" TYPE="md" SERIAL="" NAME="sdk" TYPE="disk" SERIAL="Z1F0MZ6Y" NAME="sdk1" TYPE="part" SERIAL="" NAME="md2" TYPE="md" SERIAL="" NAME="sdi" TYPE="disk" SERIAL="Z1F1ZZRJ" NAME="sdi1" TYPE="part" SERIAL="" NAME="sdg" TYPE="disk" SERIAL="5YD5RWGW" NAME="sdg1" TYPE="part" SERIAL="" NAME="md9" TYPE="md" SERIAL="" NAME="fd0" TYPE="disk" SERIAL="" NAME="md10" TYPE="md" SERIAL="" NAME="sde" TYPE="disk" SERIAL="WD-WMAWZ0247359" NAME="sde1" TYPE="part" SERIAL="" NAME="md7" TYPE="md" SERIAL="" NAME="loop0" TYPE="loop" SERIAL="" NAME="sdn" TYPE="disk" SERIAL="S1F0KCZF" NAME="sdn1" TYPE="part" SERIAL="" NAME="sdc" TYPE="disk" SERIAL="4C531001540804103384" NAME="sdc1" TYPE="part" SERIAL="" NAME="md5" TYPE="md" SERIAL="" NAME="sdl" TYPE="disk" SERIAL="Z1W1AGJX" NAME="sdl1" TYPE="part" SERIAL="" NAME="sda" TYPE="disk" SERIAL="ML0221F30431JD" NAME="sda1" TYPE="part" SERIAL="" NAME="md3" TYPE="md" SERIAL="" NAME="sdj" TYPE="disk" SERIAL="S1F01NX2" NAME="sdj1" TYPE="part" SERIAL="" NAME="md1" TYPE="md" SERIAL="" NAME="sdh" TYPE="disk" SERIAL="Z1F0L360" NAME="sdh1" TYPE="part" SERIAL=""

I've installed the update -- and the errors persist -- goes away when I uninstall the Preclear plugin.

Am I the only one getting: Sep 22 18:27:11 unraid rc.diskinfo[32461]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Sep 22 18:27:11 unraid rc.diskinfo[32461]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Sep 22 18:27:11 unraid rc.diskinfo[32461]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Sep 22 18:27:11 unraid rc.diskinfo[32461]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Sep 22 18:27:11 unraid rc.diskinfo[32461]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 If I install the Preclear plugin -- this happens and fills up my logs. When I remove it, it goes away. If it matters, I've included that "rc.diskinfo" file. (I have no clue what I am looking at) I am running: preclear plugin - 2017.09.22a (just re-installed it) rc.diskinfo.txt

I think technically the answer is that's how SMB (Server Message Block) works -- and Samba is just one of many implementations of it. Wasn't meaning to nit-pick -- but wanted to specify it wasn't a "Samba" limitation.... All SMB can do is either "advertise or not advertise" (in via the SMB 'browser' function) -- there's no mechanism to 'advertise only to certain folks' as it's a broadcast advertisement to all devices.

Had this issue trying to do a pre-clear with the drive in a cheap eSata external box -- ya know, one of those you slide in the drive bare set vertical... Putting the drive inside the server (different mounting, but also was a different disk controller) and all precleared fine x 3. Dunno if it's related to your experience.

Gotcha -- MOVE -- am in-sync with what you did now And thank you for interjecting your methodology... probably wouldn't have thought of that way, and I like the idea. Better yet, that somebody did it and it worked

Ah Bob -- hmm... while that means copying things twice -- once onto the cache drive, and then letting the mover put them back somewhere -- I do like the concept. To your point, keeps the files "available" .... I'll have to break up the moves as I have a 2TB cache drive, and effectively have about 2TB data free at the moment as well. Would need to do it in <2TB chunks. Your concept gives me something to mull over as a possible better solution -- albeit adding more 'time' involved -- but has benefits to the process. I think I'll experiment with a small subset of my DVD files. Frank -- agreed, it might not be as bad as I thought -- but due to laziness vs number of files/directories to analyze vs. missing something by hand -- I'm not sure I want to go down the road of figuring out "what's good and what's bad" about the allocation. I'm OK with treating "everything" as bad and just letting split-level / move (or cache/mover) fix it....

Ok, sue me -- I got all the way up to a 13 drive 29tb Unraid server and then realized what the fuss about "split level" was all about. I've run into the problem when a DVD rip stutters bad or completely fails during playback (and on re-start it works) because the needed disk for the "next" part must get spun up. I've also run into it with some of my photo directories where I've added more photos, and they are spread across multiple disks and it gets painful or just annoying to spin up the other drives at random and wait... Now that I realize that I need to rebalance (not sure the right word here) the server so that I have files within the subdirectories all on the same drive -- I'm wondering on the right mechanics to do this. What I've pondered doing is something like this: 1) Set the split-level properly 2) Starting on Disk1 -- rename the /mnt/disk1/DVDs folder to say -- /mnt/disk1/DVDs-temp 3) Then execute a "mv /mnt/disk1/DVDs-temp/* /mnt/DVDs" -- having unraid then "move" all the files from the referenced physical disk (Disk1) to the "share" DVDs -- and let the split-level logic take hold 4) Rinse / repeat for all the physical disks (disk2, disk3...) and again for each of the 'shares' -- 'Photos', 'Videos', etc, etc I want to set this up to execute on the unraid server itself -- to run 20+ terabytes across the network wire makes no sense.... And, of course, I want to do it 'safely' -- eg, if for some reason it burps, or whatever -- I don't want to loose anything.... Is this conceptually correct? A better way to do it?

Simple quesiton -- are you saying you did both at the same time? You can only change/remove/swap ONE drive at a time with Unraid. Change parity -- let it rebuild on the new drive. THEN AND ONLY THEN, change another drive. You can't change two drives at once. {And "trading" drives counts as changing two at once.} Or said another way -- if you have a drive that failed -- you must first 'rebuild' that drive before making any other changes to the unraid box. To recover ONE drive requires ALL OTHER drives (including the parity) to be available. It sounds like you created a self-inflicted "double drive" failure... unless I misread you. ~Update: Ignore me. See later.

I believe that is a Simple Features bug - you can from the standard GUI. LOL! Been pulling out my hair on that one. Is there an easy way to get access to the Standard GUI vs having to remove SimpleFeatures?

It's up to folks to weigh those kind of options. I tend to pay a premium for internal-style drives -- but passed it along anyway... I modified my OP to make that clear...

From 10:00AM - 12:59PM PT only 5/30/2013 WD Elements 3TB Desktop External Hard Drive - http://www.newegg.com/Product/Product.aspx?Item=N82E16822136876&Tpk=WD%20Elements%203TB%20Desktop%20External%20Hard%20Drive&IsVirtualParent=1 $99 (Remember, when you crack the case, you're likely voiding the warranty -- decide if that's worth it to you for the cost savings)

Having it in the syslog seems like a good idea to me. The information will be correct in relation to the rest of the syslog contents. Agree it's handy --as long as you remember to look at the CURRENT log. But if you happen to look at the wrong log; or simply have a copy of an earlier one and don't think about the fact that the assignments may be different, the results can be BAD I think being forced to Telnet in and execute the command virtually eliminates the possibility of using "stale" (e.g. wrong) data r.e. the assignment. I think that's easily fixed by including in the syslog a warning "**** THIS INFORMATION VALID FOR THIS BOOT ONLY ****" or something above/below the text block of ata?=sd? messages.

You typed, while I updated my post!

Thanks Joe, for my purposes that script solves the mystery. ata9 = sdf -- happens to be my cache drive, in an external eSATA enclosure. Ugh. Will work on that issue.... I have enough info now to trade the 'cache disk' with another drive, and see if the 'problem' moves with the drive (eg, it's a drive issue) or stays with the eSata -- ergo, is a controller/cable/eSata issue... {I think the latter} However, I do have 13 drives in my array (12 + cache) -- and the script didn't identify everything. So others usage of it may not be 100% successful for this exercise. As a side note -- my 'suggestion' would be for UnRaid -- in some future version -- to include this (or an enhanced script) and have it run automatically as part of the boot-load -- so it puts these "rosetta stone" (ataX=sdX) messages into the syslog. Would help a lot ~Update: Ah, I bet the 6 drives that aren't identified -- are the ones that are on the 6-port SuperMicro controller (AOC-SASLP-MV8) -- so perhaps the script could be tweaked {uh, not in my skill set} by someone, eventually... being that's a common/recommended controller ...Chuck root@unraid:/boot# chmod +x ata_devices.sh root@unraid:/boot# ./ata_devices.sh (Device sda is not an ATA device, but a USB device [e. g. a pen drive]) sdb: ata3.00 sdc: ata4.00 sdd: ata5.00 sde: ata6.00 sdf: ata9.00 sdg: ata10.00 sdh: ata19.00 sdi: ata20.00 cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:0/end_device-1:0/target1:0:0/hostsdj/scsi_host/hostsdj/unique_id: No such file or directory : ata. cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:1/end_device-1:1/target1:0:1/hostsdk/scsi_host/hostsdk/unique_id: No such file or directory : ata. cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:2/end_device-1:2/target1:0:2/hostsdl/scsi_host/hostsdl/unique_id: No such file or directory : ata. cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:3/end_device-1:3/target1:0:3/hostsdm/scsi_host/hostsdm/unique_id: No such file or directory : ata. cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:4/end_device-1:4/target1:0:4/hostsdn/scsi_host/hostsdn/unique_id: No such file or directory : ata. cat: /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/host1/port-1:5/end_device-1:5/target1:0:5/hostsdo/scsi_host/hostsdo/unique_id: No such file or directory : ata. root@unraid:/boot#

Ugh, no. I'm showing zero's across the board for errors... I was afraid of that. I'll have to get deeper into my SMART checks. I at least know it's one of my 5 3TB ST3000DM001 Seagates - out of 13 drives... (Of other MFGs, Size, or Model #'s} Ugh. It "seems" to me there ought to be a better way to do a definitive match from "ataX" number to "it's this drive" -- but oh well... I'll quit expecting an easy way to do this Once I track down the drive, I want to "trade" that drive into another slot/controller -- and see if the problem follows the drive, or stays with the controller. I am assuming that "ata6" would stay consistent -- that is, it's a "hardware" descriptor, of a SATA port... or am I asking to much that "ata6" would mean the same thing (data path) between reboots?

Yea, I searched and saw that line in the syslog.... I have several ST3000DM001 disks. And none show 1CH166 -- in fact, the drive identifiers shown on the Unraid main page are longer -- like "ST3000DM001-9YN166_Z1F0MZ6Y" and "ST3000DM001-9YN166_Z1F0L360" -- etc... So, how do I match 1CH166 to something? Where should I be looking to find the "1CH166"...

I'm getting errors like: May 13 08:29:33 unraid kernel: ata9: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0 (Errors) May 13 08:29:33 unraid kernel: ata9: irq_stat 0x40000001 (Drive related) May 13 08:32:06 unraid kernel: ata9: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0 (Errors) May 13 08:32:06 unraid kernel: ata9: irq_stat 0x40000001 (Drive related) How do I identify what disk is ata9 -- as I understand it, the 'ata' number is related to the disk channel, not necessarily "disk9" Attached syslog syslog-2013-05-13.zip

Not sure I remember -- Quote from: chuck23322 on May 07, 2012, 12:00:09 PM Probably was a torrent... most of my avi's then were. My issues were solved by upgrading my 5.0 and me no longer using "root" to mount shares. And working out my Windows boxes who were caching credentials still to 'root' (changed root's PW to fix that and used a 'user' account) Another user 'bumped' this thread having similar problems.

Concur. I just edited my "old" post to strike-out my prior attempts. Upgrading the version level of 5.0 and running the New Permissions is a MUCH better solution. @Others - So is, ensuring, that you are NEVER using 'root' to mount shares, etc -- I think that got disabled {so you can't} -- but in any case, don't do it Create a user account using the menus in UnRaid and always access your shares that way. The difficulty I and others encountered with changing to this, is that WIndows has a nasty habit of 'caching' credentials -- so it may require to also change the password of 'root' so that you force Windows not to connect with old credentials.

Please let us know your results. Good luck.