remotevisitor

Both me and my brother have had this problem for some time in our unRAID systems which began when we started putting WD WD60EFRX drives into our system connected to an AOC-SASLP-MV8 board. Setting these drive to not spin down made the problems go away; so a work-around but not an ideal solution (especially when I do a new config and forget to turn off the spin down on these drives and the have to do a file system check and check/rebuild parity when it subsequently goes wrong). However my brother has not had the problem since he left the drives with the normal default spin down on the latest beta14b, whilst I on the latest beta have had a problem (after I forget to turn off the spin down after a new config) and therefore resorted back to ensuring my WD WD60EFRX drives do not spin down.

What values have you specified for the 'split level', 'include disks'/'exclude disks' and 'allocation method' for the 'Home Movies' share as these control where new files will be written?

I suspect it is the parity check that is run on the 1st of the month (unless you change the default setting) that was added in the latest beta.

Isn't it disk 6 and not disk 2 that has the pending sectors?

I would guess because Unraid 6 is 64-bit and does not include support for running 32-bit binaries.

This is almost certainly an indication that file system corruption has been detected on the drive and it has therefore been mounted read-only to prevent any further problems occurring. The corrective action will be to stop the array and then use the reiserfsck command to fix the problem. If you search this forum for articles about using reiserfsck I am sure you will find suitable advice. If you are unsure what to do, stop and ask for advice before continuing.

There is a special procedure called swap-disable ( http://lime-technology.com/wiki/index.php/UnRAID_Manual#Replace_a_failed_disk ) to handle the situation where the replacement disk is bigger than the existing parity. Basically it copies the original parity to the new bigger disk and then recovers the failed disk to the one which was the original parity disk

Try setting the WD 6Tb disk to not spin down. On both mine and my brother's Unraid systems we have found that there appears to be an issue with WD 6Tb drives that they sometimes appear to have issues restarting after they have spun down; which is just what is likely to occur when mover starts overnight. Setting our 6Tb disks to not spin down appears to have solved the issue for us. It would be interesting to see if the same goes for you.

The syslog shows that it is only detecting a "Basic" registration key, which is the free one which supports 3 drives .... Parity and 2 data. From your description you stated that you had replaced the flash drive ..... Purchased licenses are "locked" to the serial number of the flash drive; so if you have changed the flash drive your license key will no longer be working and it will default to the free license. I would suggest that you try with a clean install on your original flash drive, ensuring that you place a copy of your purchased license in the config folder. If you need to have your license transferred to a new flash drive you have to contact LimeTech support and arrange to have the license re-issued for the new flash drive.

Looks like your Ubuntu VM is defaulting to include the -N option to ls.

For the 2nd problem use the command line option '-i Movies' rather than '-i /mnt/user/Movies' ... The /mnt/user is automatically added to what is supplied to the -i parameter's value.

The most likely cause is the the flash drive is being mounted read only because of a problem detected with the file system on it. Shutdown unraid, remove the flash drive. Connect it to a PC/Mac and run a checkdisk on it to fix any problems file system problems, eject the flash drive and put it back into your unRAID system and boot.

I suspect that there is a file & folder with the same name but on different disks ... One being a folder and the other being a file. Try doing something like ls -ld /mnt/disk*/...... Where you replace ....... With the path to your problem file/folder. You will probably find it returns 2 entries; one being a file and one being a directory.

Was Disk 6 a replacement for a disk that was previously 500Gb? The auto-expand of the filesystem on a replacement disk being disabled is detailed in the 1st post of this thread as a known issue in Beta 7 and is not fixed in Beta 8. I think this issue is expected to be fixed in Beta 9 (but until Beta 9 is actually released we won't know for sure).

Are you by any chance running cache_dirs? This would certainly be running a regular find on your disks. If the answer is yes then it may be you need to add/change some parameters to modify its behaviour on your system.

I suspect that although you say disk 1 and 2 are full up, there may actually be a very small amount of space still unused. As you have nothing set in the Min. Free space field it will try to use one of thsee disks but then very quickly give an out of space error. So my suggestion would be to set the min free space with a value which is larger than the largest file you are likely to write; this will then ensure unraid finds a disk with at least this amount of free space before it starts writing the file .... which should then make it write to disk 3 or 4.

The directory you are attempting to remove is called "OLD" but the directory you are attempting to remove with the "rm" Command is a directory called "old". Directory and filenames are case-significant. Therefore try the command suggested by dgaschk which has the directory with the correct case.

4.7 doesn't support 3Tb disks. If you want to use disks larger than 2Tb you must use 5.0 (currently RC16c)

To delete a file requires that you have write access to the directory containing the file, not the file itself. So maybe you need to run newperms on the directory containg the file and not just the file ..... Note that this will also change the permissions on any files or directories within the specified directory.

Sending a SIGHUP to Samba is the way of telling Samba to reread it's configuration file so is nothing to worry about. I suspect the times it has appeared in the log is when you have done something (like changing share settings) that might have resulted in changes to the Samba configuration.