beelyte

I've set up an Ubuntu guest, mapped an Unraid-share to a mount point in it's configuration and edited fstab within the guest, so that I have read/write access to that share. That works absolutely fine. Then I've created a share with the plugin "Unassigned Devices" on a drive outside the array. It's mounted to /mnt/disks/temp. "Unassigned Devices" is configured to export the share without SMB Security. And the share has the same permissions as the working one from within the array. I can read/write access it from a windows machine. But when I create a mount point for the Linux-VM and edit fstab, so that it points to the "Unassigned Devices" share, then I only have read access to the share. I can open the files, but can't edit existing files or create new files. Is this a bug or am I missing something? Thank you for your help! Thomas

I used core 0 of my Xeon E3-1246v3. It worked immediately, so I didn't try another one.

Switching to one core did the trick. Thanks for your help! :-)

I have exactly the same problem, using a Supermicro X10SAE. Windows Update finds the new version but fails when it tries to install it. Installation of the 10162 Build from ISO doesn't work either. Windows crashes on first reboot and reverts everything back to the previous state of Build 10130.

Then I'll bite the bullet now and do the correcting parity check. That's a good idea to compare the data with the backups. I'm doing the backups with SyncBack SE. I remember an option for bit-wise comparison. Thanks for your advice! *starting parity check*

I did a parity check, that's why I stumbled upon the read erros on the 2,5TB-Drive. There were no sync errors reported, but 66 read errors on the mentioned drive. So I decided to exchange the drive.

A 2,5TB Disk of my array with 3TB parity had read errors, so I replaced it with a 4TB Disk. I thought I could use 3TB of this 4TB disk because of the smaller parity drive, but unRaid told me to do a swap-disable. After a bit of reading in the forums I did as told. unRaid copied the parity drive to the new disk, rebuilt the 2,5TB drive on the former parity disk and expanded the array. Then I started the parity check. Every now and then I looked at the progressing parity check via webgui and everything looked fine. But now at nearly 90% complete, I looked again and I have thousands of sync errors, starting in sector 5860533064 and then all eight sectors. Is that because I didn't preclear the parity disk, so that the part of the disk > 3TB is not initialized? Should I do a second parity check with correcting parity and everything is back to normal? Thanks for your help! syslog.txt

Here is another unknown MBR after installing 5.0b6a over 5.0b4. It's a WD EARS20, connected to an Adaptec 1430SA, never used in an other system. But on earlier betas. root@Atlas:~# sfdisk -luS /dev/sdc Disk /dev/sdc: 243201 cylinders, 255 heads, 63 sectors/track Warning: The partition table looks like it was made for C/H/S=*/1/0 (instead of 243201/255/63). For this listing I'll assume that geometry. Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdc1 63 3907029167 3907029105 83 Linux /dev/sdc2 0 - 0 0 Empty /dev/sdc3 0 - 0 0 Empty /dev/sdc4 0 - 0 0 Empty root@Atlas:~# cat /sys/block/sdc/size 3907029168 root@Atlas:~# dd status=noxfer count=1 if=/dev/sdc | od -Ad -t x1 1+0 records in 1+0 records out 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 3c a2 5f 38 00 00 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512