unRAID Server release 4.5-beta6 available

[RobJ]

Tom, please look at the following, and his syslog1.

 

I originally took a very quick glance at syslog1, and saw such a horror show, with multiple things wrong and many drives unable to mount, that I then moved to syslog2, and found nothing at all wrong.  When you see too many things wrong, you have to assume you can't trust most of the error reports, because there is something systemically wrong with the system.  You have to first clear up the systemic problem, before you can determine what else is truly an issue, and not just 'collateral damage'.  If a person has a serious fever, they also have a wide variety of other symptoms, including achy legs.  If I spend much time trying to diagnose what is wrong with the legs, I will be completely wasting my time.  We first 'reboot' the system to remove the virus, then check to see if the legs are still achy.

 

After that brief look, I wasn't particularly eager to re-examine syslog1, but from your comments, decided to take a longer look, with the idea that I would ignore all of the collateral damage, and look for what precipitated all of the trouble.

 

And it was not hard to find, as it occurred almost immediately.  The errors all appear to be those that are typical of a bad cable.  This whole mess may have been because of a single bad cable!  And then more trouble surfaced, rather serious, and may require Tom's attention.  Below are extracted lines from your syslog, that help to provide a timeline.  It's a sad and troubling tale.  It looks like it tries to start the array, AND start a parity check (not sure about this), AND start a drive rebuild, but the drives won't mount.  Disk 8 then falls into a long cycle of repeating error sequences, that I call 'drive limbo-land' (shown below), until it is finally disabled.  From what I can see, drive and controller are fine, cable is bad.

 

I still think you should, after replacing cable (!), un-assign Disk 8, reboot, re-assign Disk 8, and Start the array to rebuild Disk 8.  I would wait for others to confirm or advise better.

 

'Drive limbo-land cycle'

  1. System:  Drive is good.  Send it a task.

  2. Drive:    "What's that?  I can't hear you.  Too much static."

  3. System: Call the doctor.                        [ EH, the error handler, is the doctor ]

  4. Doctor:  Hard reset it.  Drive responds correctly.  Drive is fine.  Drive is cleared to return to work.

  5. Return to Step 1.

It's a never-ending loop, can't get productive work done, can't fail the drive either.

 

May 28 14:59:55 Tower kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May 28 14:59:55 Tower kernel: ata1.00: ATA-7: SAMSUNG HD103UJ, 1AA01113, max UDMA7
May 28 14:59:55 Tower kernel: ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
May 28 14:59:55 Tower kernel: ata1.00: configured for UDMA/133
May 28 14:59:55 Tower kernel: scsi 1:0:0:0: Direct-Access     ATA      SAMSUNG HD103UJ  1AA0 PQ: 0 ANSI: 5
May 28 14:59:55 Tower kernel: sd 1:0:0:0: [sda] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)

May 28 14:59:55 Tower kernel:  sda: unknown partition table

May 28 14:59:55 Tower emhttp: unRAID System Management Utility version 4.5-beta6

May 28 14:59:55 Tower emhttp: pci-0000:00:1f.2-scsi-0:0:0:0 (sda) ata-SAMSUNG_HD103UJ_S13PJDWS323727

May 28 14:59:55 Tower emhttp: get_fstype: open /dev/sda1: No such file or directory

May 28 14:59:55 Tower kernel: md: import disk8: [8,0] (sda) SAMSUNG HD103UJ                          S13PJDWS323727       offset: 63 size: 976762552
May 28 14:59:55 Tower kernel: md: disk8 replaced

May 28 15:04:17 Tower emhttp: writing mbr on disk 8 (/dev/sda)
May 28 15:04:17 Tower emhttp: re-reading /dev/sda partition table
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Write Protect is off
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 28 15:04:17 Tower kernel:  sda: sda1
May 28 15:04:17 Tower kernel: ata1.00: exception Emask 0x50 SAct 0x0 SErr 0x280900 action 0x6 frozen
May 28 15:04:17 Tower kernel: ata1.00: irq_stat 0x08000000, interface fatal error
May 28 15:04:17 Tower kernel: ata1: SError: { UnrecovData HostInt 10B8B BadCRC }
May 28 15:04:17 Tower kernel: ata1.00: cmd c8/00:08:00:02:00/00:00:00:00:00/e0 tag 0 dma 4096 in
May 28 15:04:17 Tower kernel:          res 50/00:00:e7:01:00/00:00:00:00:00/e0 Emask 0x50 (ATA bus error)
May 28 15:04:17 Tower kernel: ata1.00: status: { DRDY }
May 28 15:04:17 Tower kernel: ata1: hard resetting link
May 28 15:04:17 Tower kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May 28 15:04:17 Tower kernel: ata1.00: configured for UDMA/133
May 28 15:04:17 Tower kernel: ata1: EH complete
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Write Protect is off
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
May 28 15:04:17 Tower kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  [ many repeats of 'exception Emask' through 'Write cache: enabled'; the main difference being the decreasing SATA link speed (1.5) and UDMA mode (UDMA/33) ]

May 28 15:04:18 Tower emhttp: get_fstype: open /dev/sda1: No such file or directory

May 28 15:04:18 Tower kernel: ata1: EH complete
May 28 15:04:18 Tower kernel: md: import disk8: [8,0] (sda) SAMSUNG HD103UJ                          S13PJDWS323727       offset: 63 size: 976762552
May 28 15:04:18 Tower kernel: md: disk8 replaced
May 28 15:04:18 Tower kernel: md: import disk9: [8,176] (sdl) SAMSUNG HD103UJ                          S13PJ1NQ713356       offset: 63 size: 976762552
May 28 15:04:18 Tower kernel: mdcmd (6): start

May 28 15:04:18 Tower kernel: md8: running, size: 976762552 blocks

May 28 15:04:18 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x280100 action 0x6 frozen
  ... [ repeat of error lines above ]
May 28 15:04:18 Tower kernel: ata1: EH complete
May 28 15:04:18 Tower kernel: ata1: limiting SATA link speed to 1.5 Gbps

May 28 15:04:21 Tower kernel: end_request: I/O error, dev sda, sector 327
May 28 15:04:21 Tower kernel: Buffer I/O error on device sda1, logical block 264     [ repeats through block 273 ]

May 28 15:04:21 Tower kernel: ata1: EH complete
May 28 15:04:21 Tower emhttp: shcmd (22): mkdir /mnt/disk1
May 28 15:04:21 Tower emhttp: shcmd (23): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md1 /mnt/disk1  >/dev/null 2>&1
May 28 15:04:21 Tower emhttp: shcmd (23): mkdir /mnt/disk2
May 28 15:04:21 Tower emhttp: shcmd (24): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md2 /mnt/disk2  >/dev/null 2>&1
May 28 15:04:21 Tower kernel: sd 1:0:0:0: [sda] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)
May 28 15:04:21 Tower kernel: mdcmd (8 ): check                                                  [ parity check begun ? ? ?  *** ]
May 28 15:04:21 Tower kernel: md: recovery thread woken up ...
May 28 15:04:21 Tower kernel: md: recovery thread rebuilding disk8 ...                      [ drive rebuild begun ]
May 28 15:04:21 Tower emhttp: shcmd (24): mkdir /mnt/disk3
May 28 15:04:21 Tower emhttp: _shcmd: shcmd (24): exit status: 32
May 28 15:04:21 Tower emhttp: disk1 mount error: 32                                            [ Disk 1 fails to mount  *** ]
May 28 15:04:21 Tower emhttp: shcmd (25): rmdir /mnt/disk1
May 28 15:04:21 Tower emhttp: shcmd (26): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md3 /mnt/disk3  >/dev/null 2>&1
May 28 15:04:21 Tower emhttp: _shcmd: shcmd (27): exit status: 32
May 28 15:04:21 Tower emhttp: disk2 mount error: 32                                            [ Disk 2 fails to mount; repeated for all other data drives ]
May 28 15:04:21 Tower emhttp: shcmd (28): rmdir /mnt/disk2
May 28 15:04:21 Tower emhttp: shcmd (28): mkdir /mnt/disk4

May 28 15:04:21 Tower kernel: md: using 1152k window, over a total of 976762552 blocks.

May 28 15:04:21 Tower kernel: ReiserFS: sdi1: found reiserfs format "3.6" with standard journal   [ only the Cache drive mounts successfully ]

May 28 15:04:22 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May 28 15:04:22 Tower kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100)
May 28 15:04:22 Tower kernel: ata1.00: revalidation failed (errno=-5)
May 28 15:04:27 Tower kernel: ata1: hard resetting link
May 28 15:04:27 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May 28 15:04:27 Tower kernel: ata1.00: configured for UDMA/100
May 28 15:04:27 Tower kernel: ata1.00: limiting speed to UDMA/33:PIO4      [ Disk 8 is dropped in speed ]
   [ many more sequences of the errors above, 'drive limbo-land cycle'; continues repeating wherever blank lines are below ]
May 28 15:04:39 Tower emhttp: shcmd (54): /etc/rc.d/rc.nfsd restart | logger                 [ unRAID is just now completing its boot ]

May 28 15:05:40 Tower emhttp: shcmd (55): /usr/sbin/hdparm -y /dev/sda >/dev/null            [ yikes!  trying to spin down Disk 8???  *** ]

May 28 15:07:45 Tower emhttp: shcmd (56): /usr/sbin/hdparm -y /dev/sda >/dev/null            [ yikes again! ]

May 28 15:12:52 Tower emhttp: shcmd (57): /usr/sbin/hdparm -y /dev/sda >/dev/null            [ yikes again! ]

May 28 16:40:31 Tower kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100)
May 28 16:40:31 Tower kernel: ata1.00: revalidation failed (errno=-5)
May 28 16:40:31 Tower kernel: ata1.00: disabled                                           [ finally!!! *** ]

May 28 16:40:32 Tower kernel: end_request: I/O error, dev sda, sector 4707991
May 28 16:40:32 Tower kernel: md: disk8 write error
May 28 16:40:32 Tower kernel: handle_stripe write error: 4705880/8, count: 1
May 28 16:40:32 Tower kernel: md: disk8 write error
May 28 16:40:32 Tower kernel: md: md_do_sync: got signal, exit...
May 28 16:40:32 Tower kernel: handle_stripe write error: 4705888/8, count: 1                    [ many more of this line and the next line ]
May 28 16:40:32 Tower kernel: md: disk8 write error                                            [ these can be ignored, because drive is disabled ]

May 28 16:40:32 Tower kernel: md: recovery thread sync completion status: -4
May 28 16:40:32 Tower kernel: md: recovery thread woken up ...
May 28 16:40:32 Tower kernel: md: recovery thread has nothing to resync
May 28 19:40:33 Tower emhttp: shcmd (58): /usr/sbin/hdparm -y /dev/sdj >/dev/null          [ drives begin spinning down ]

May 28 19:40:49 Tower emhttp: shcmd (67): /usr/sbin/hdparm -y /dev/sda >/dev/null
May 28 19:40:49 Tower emhttp: _shcmd: shcmd (67): exit status: 5                            [ end of syslog ]

[madshi]

Thanks, Rob. At this point in time I'm a bit concerned about losing data. So just to be sure I'll wait if Tom or Joe will agree with your advice, since you don't seem to be 100% sure yourself.

 

BTW, the problem started after power went off (unexpectedly) for a few minutes. After the next boot suddenly that one harddisk was "red" on the status page. Not sure if a power outage can make a cable go bad. I thought it was more probable that either the harddisk or the controller were affected by the power outage. But who knows...

[SlowNIC]

I'm getting a Kernel OOPS with more than 16 drives.

 

I had an array that I've been using for 4 months.  It has 16 drives of the same model number.  I added an additional 4 drives of the same model number.

Here are my steps:

 

1. Add the 4 drives, but only connect the power cords, not the SATA cables.  Test for enough power and cooling.  Ran for two days without issues.

2. Connect one of the new drives to a spare port on the mainboard.  This port is on the Promise PDC42819 and we're using AHCI.  Boot-up add the drive in the "drives" screen as disk16, back to main, "restore", "start" - generate parity.  As soon as I hit start, I get the Kernel OOPS.

3. Undo step 2 and move some of the existing drives to fully populate the Promise PDC42819 ports on the mainboard.  We're still at 16 drives - go to the devices screen, shuffle accordingly, remove disk16.  Back to main, "restore", "start" - generate parity.  Works.  Wait for parity sync to complete.  Watch movies...

4. Next day - connect a different new drive to a spare port on the Adaptec 1430sa controller.  We go into devices screen, add disk16, and back to main, restore and start - Kernel OOPS.

5. Undo step 4.  Move some existing drives from the sata_sil24 controllers to fully populate the Adaptec 1430sa, reconfigure for 16 drives, start - everything works, generate parity, watch movies....

6. Next day - connect a different new drive to a spare port on the sata_sil24 controller.  We go into the devices screen, add disk16, and back to main, restore and start - Kernel OOPS.

7. Undo step 6. Move some existing drives from the SB600 controller on the mainboard to fully populate the sata_sil24 controllers, reconfigure for 16 drives, start - everything works, generate parity, watch movies.....

8 Next day - connect a different new drive to a spare port on the SB600 mainboard controller.  We go into the devices screen, add disk16, and back to main, restore and start - Kernel OOPS.

 

Get the idea?

 

The point is that these controllers have been happy in my system for months.  I've had the 16 disks distributed among these controllers so that I would balance the load.  No matter which controller I add disk16 (the 17th disk) to, the Kernel OOPS happens.  It is independent of which new disk I pick or which controller I add it to.

 

I'd bet that there is still some data structure somewhere that has a 16 disk limit and that I'm trashing memory.  It's visible on my system due to the combination of drivers, perhaps?

 

I had one of the OOPS in an emacs buffer on another system.  Most of the time the OOPS will crash the system, but the one time it didn't I captured it in the emacs buffer.  Unfortunately, I did not save the buffer before I did a reboot of that system.

 

unRAID Server Pro

4.5-beta6

Linux Tower4 2.6.29.1-unRAID #2 SMP Thu Apr 23 14:17:18 MDT 2009 i686 AMD Athlon X2 Dual Core Processor BE-2400 AuthenticAMD GNU/Linux

sata_sil24 (4 controllers, 2 ports each, 8 ports total)

sata_mv (adaptec 1430sa, 1 controller, 4 ports each, 4 ports total)

sata_ahci (promise PDC42819, SB600, 2 controllers, 4 ports each, 8 ports total)

atiixp (single IDE cache disk)

 

Other than capturing more data, is there some procedure I can try to get a smoking gun?

 

Thanks in advance.

 

[cwr]

there was someone else having this same problem re: 16 drives on the forum, i guess tom is lokoing into it

[madshi]

The errors all appear to be those that are typical of a bad cable.  This whole mess may have been because of a single bad cable!

Amazing - you seem to have hit the nail on the head!

 

Just replaced that one cable and the problem seems to be gone. I've also put back in that old harddisk which I thought had failed - and it's working fine again. Just to be safe I've now swapped the disks so that the cache is connected to the problematic controller/cable. So if something goes wrong again, only the cache disk is affected. Anyway, my unRAID array seems to be happy again. Thanks much for your help!

[RobJ]

I upgraded from beta 4, I set my drives to never spin down. However in this build, despite them being set to never spin down, they do anyway. Is anyone else having this problem?

 

Please display the contents of your disk.cfg file, located in the config folder of your unRAID flash drive.

[RobJ]

You have it configured correctly.  The only other way I know to explain why the drives are spinning down, is that you may have once added spin down commands in your go script?  They would instruct the hard drives on each boot to manage their own built-in spin down timers.  As far as I know, that is not preserved across power off, so if you have powered down, the only way there would still be a spin down in operation is if it still is being set within your go script.

[Joe L.]

I never noticed the "sleep 30" would that be causing my problem?

No, it just waits there 30 seconds for the array to be started before continuing the rest of the "go" script and setting the read-ahead buffer on the "md" devices.  If it did not wait, the devices would not yet exist, as the array would still be starting up.

 

Nothing there sets the spin-down.

 

Joe L.

[RobJ]

Stephen, are you saying that you can power the system completely off, then after booting unRAID, some or all drives will spin down?  After what interval?

[Joe L.]

Stephen, are you saying that you can power the system completely off, then after booting unRAID, some or all drives will spin down?  After what interval?

 

Correct I restart unraid from the web interface then after booting, all the drives spin down. To make sure, i restarted last night and this morning all the drives were spun down. I will try and figure out the interval.

Did you "restart" unraid by rebooting, or powering off, and then powering back on again? 

I would think the reboot would not change any old existing disk timeout interval, but a power-cycle would.

 

Joe L.

[RobJ]

Any other ideas or just wait till beta 7?

 

I don't so far see how it could be related to unRAID.  If it is unRAID spinning the drives down, then there will be spin down commands in the syslog, at the time of spin down.  They look similar to the following (the command to spin down sda):

emhttp: shcmd (39): /usr/sbin/hdparm -y /dev/sda >/dev/null

[Joe L.]

Try using the hdparm command to set the timeout to disabled... It could be your drives remember the last timeout value given, and that now that Tom is doing the timing in his process, the disks remember how they used to be set.

 

For each of the drives, put a line like this in your "go" script.  (That is capital "S" followed by a zero in the command below)

 

hdparm -S0 /dev/sd?

For certain drives, you might also try

hdparm -Z /dev/sd?

You need to replace the "sd?" with your device names.  (If IDE drives, they will be "hda,hdb,hdc,..." for SATA drives, "sda,sdb,sdc,etc...)

 

You can do it in a loop with this

for i in /dev/[sh]d?

do

  hdparm -S0 $i

done

 

Joe L.

[Joe L.]

@ RobJ

I just thought it would be related to unraid as this did not occur with beta 4 and only presented itself when I upgraded to beta 6. All my hardware has remained the same. I have searched my log but can find no lines that would indicate unraid it spinning them down.

 

@ Joe L.

I copied

 

for i in /dev/[sh]d?

do

  hdparm -S0 $i

done

 

into my "go" script, but the problem still exists. Should i avoid the looping script and try hdparm -S0 on each drive individually?

You can try...

[SSD]

There is a jumper on drives indicating that drives should power up in standby mode.  Is it possible that jumper is installed on these drives?

[WizADSL]

I see that unraid notify is in your go script, unraid notify has a parameter in its config file that imples that it will spin drives down:

 

The last few lines in my unraid_notify.cfg file:

 

# How long to wait for disk activity, in minutes, before spinning down an idle drive
# warning: Setting too low of a spindown time can prematurely age your drive by forcing
# too many spin-up/down cycles on the poor thing.
SpinDownTime = 60

[brainbone]

into my "go" script, but the problem still exists. Should i avoid the looping script and try hdparm -S0 on each drive individually?

 

Just a side note;  If you're using unraid notify, I haven't yet added the ability to disable spin-down -- so if you are using unraid notify, it could be the one spinning down your drives.

[str1der]

Was running version 3.X up until a few weeks ago. This thing was rock solid. I did an upgrade to 4.5 beta 6 and since then I've been averaging the server going down at least 1 time a week. Is this happening to anyone else?

[somail]

Was running version 3.X up until a few weeks ago. This thing was rock solid. I did an upgrade to 4.5 beta 6 and since then I've been averaging the server going down at least 1 time a week. Is this happening to anyone else?

 

I have noticed slower write times, and connectivity problems.  But nothing catastrophic. 

[RobJ]

Was running version 3.X up until a few weeks ago. This thing was rock solid. I did an upgrade to 4.5 beta 6 and since then I've been averaging the server going down at least 1 time a week. Is this happening to anyone else?

 

I am not aware of any reports consistent with that.  unRAID v4.5-beta6 has been very stable.  Can you provide some specifics about the problems and errors you have seen?  Have you been able to capture a syslog before it went down?

[jupilerman]

I did downgrade to 4.5.beta 4 because 4.5.6 freeze at least one time a day.

4.5.4 works perfectly for me.

 

This could be a hardware issue. Some works fine with 4.5.6, some doesn't.

[SSD]

I did downgrade to 4.5.beta 4 because 4.5.6 freeze at least one time a day.

4.5.4 works perfectly for me.

 

This could be a hardware issue. Some works fine with 4.5.6, some doesn't.

 

You might want to test your RAM.

[RobJ]

I did downgrade to 4.5.beta 4 because 4.5.6 freeze at least one time a day.

4.5.4 works perfectly for me.

 

This could be a hardware issue. Some works fine with 4.5.6, some doesn't.

 

It's possible, with the huge number of changes that occur in each Linux kernel release, that a compatibility issue will arise with a particular release and specific hardware components, and then be resolved in a later release.  In this case, reverting back to a previous release, and awaiting a future release is correct.

 

But it is also possible that a bug has been introduced with an unRAID release, but with only rare effects, and it would be good to see it resolved too.  That can only be done by assistance from one or more of the specific users affected by it.  I do understand that many users do not have the time and/or interest in helping, but such a rare issue may never be resolved, unless someone steps up, to at least provide some detail.

 

I would like to encourage anyone who has experienced an issue that has caused them to revert, especially an issue that does not appear to be handled yet, to consider doing a little exploratory testing, to report symptoms and error messages and relevant syslogs, along with their specific hardware setup.  A bug that only affects a few users is not likely to ever be resolved, if no one does any reporting or testing.  I'm not trying to lay a guilt trip here, just remind people of the reality of software development, especially with a relatively small user base.

[SSD]

I did downgrade to 4.5.beta 4 because 4.5.6 freeze at least one time a day.

4.5.4 works perfectly for me.

 

This could be a hardware issue. Some works fine with 4.5.6, some doesn't.

 

It's possible, with the huge number of changes that occur in each Linux kernel release, that a compatibility issue will arise with a particular release and specific hardware components, and then be resolved in a later release.  In this case, reverting back to a previous release, and awaiting a future release is correct.

 

But it is also possible that a bug has been introduced with an unRAID release, but with only rare effects, and it would be good to see it resolved too.  That can only be done by assistance from one or more of the specific users affected by it.  I do understand that many users do not have the time and/or interest in helping, but such a rare issue may never be resolved, unless someone steps up, to at least provide some detail.

 

I would like to encourage anyone who has experienced an issue that has caused them to revert, especially an issue that does not appear to be handled yet, to consider doing a little exploratory testing, to report symptoms and error messages and relevant syslogs, along with their specific hardware setup.  A bug that only affects a few users is not likely to ever be resolved, if no one does any reporting or testing.  I'm not trying to lay a guilt trip here, just remind people of the reality of software development, especially with a relatively small user base.

 

I had a problem a few releases ago that went away when I went back to the prior version.  After testing memory, I found I had a memory error.  Removing the offending memory stick fixed the problem.  I suspect that the way memory was allocated resulted in the bad memory addresses moving from an unimportant area to an important area.  As I said, I suggest you test RAM as the first step.  Some new incompatibility is certainly possible, but has been surprisingly rare.

[intoran]

Does anyone know the ETA for the final release?  OR what kernel it will be based on?

[bburns]

I just built an Unraid Server using rel 4.5 beta 6 for evaluation.  I am having difficulties with the "share" feature. I created several shares using  the web based tool. When I browse the Tower from a Windows XP or Vista box, I see only "flash" and "printers". If I type the path "\\Tower\disk1" in the explorer's address box, then I see the shares listed or if I type "\\Tower\<share name>" in the address box, I see the contents of the share. Why would the shares not show up when I do "\\Tower"? I have tried this across several machines and I get the same results:(

 

Now I created the folder  "\\Tower\Disk1\Test" from Windows Explorer and did not add it via the web tool. This now appears as a share in explorer under the root: "\\Tower\Test" and it appears to have automagically created the share in the Web Tool.

 

So how do i make the shares that I created from the Web Tool appear at the root. I have already moved alot of data to them, so I do not relish the idea of moving the data.