itimpi

Have you just enabled the cache disk? The /mnt/user0 folder appears when you have user shares active and a cache disk.

I am also finding that my NIC (RTL 8111E) is not working with rc12 where it worked fine on rc11. The information reported by ethtool on rc11 are: driver: r8168 version: 8.035.00-NAPI firmware-version: bus-info: 0000:05:00.0

I wonder what is causing the memory release? If at that time the cached directory entries for cache_dirs are also getting flushed from memory that would explain the disks spinning up as now they actually have to be read to get the directory entries the next time cache_dirs attempts this.

Now might be a good time to make the jump to the 5.0 series before you get too much set up on the unRAID system. You are going to need to make the jump if you want to use any drive larger than 2TB anyway and with 3TB and 4TB drives coming down in price rapidly I would have expected if you buy a new drive it is likely to be of that sort of capacity.

There is a known issue with ReaiserFS file systems (on all systems, not just unRAID) in that they start slowing down significantly for adding new files as they get very full. I expect this is what you are seeing?

If TV is the share name, then with a structure of TV/Series Name/Season/files the TV and Series Name levels are allowed to be across multiple disks. Once a Season folder is created then its contents will be constrained to the disk on which the Season folder was created. If you wanted each Series name to be constrained to a single disk then you would only want level 1. This does not explain why you were getting your original problem of files not being split across disks as expected!

It was not clear whether the first element you mention is the share name or the folders within the share? The point is that the share name counts as the first level. If your share is called Movies then level 2 is probably correct for what you want. However if the share is o something like 'media' and within that you have Movies and TV then you would need the third level. I was only guessing earlier as your symptoms would be explained by the share level being wrong.

That sounds correct if Movies and TV are you share names. However if they are folders UNDER the share you would need level 3 or the movies and TV Show contents would be constrained to the disk they were first created on as the share name counts as the first level.

What split level are you using? What does your top level folder structure look like? Split level takes precedence over the free-space algorithm, so an incorrect split level for the folder structure you want to use can force new files/folders to a particular disk.

If you go in via the share then it is called 'flash'. If you are in a telnet session, then the flash drive is mounted as /boot. Therefore which of these you use depends on the context.

I suspect you may largely get away with this! The main Linux file system will not be affected as this is loaded fresh each time the system boots. Your flash drive (/boot) uses a FAT based file system that does not support access permissions so this is unlikely to be a problem. The issue comes down to files on your shares. If you are using the 5.0RC11 release then the 'newperms' command can be run to set all files back to their normal default permissions and access rights. If you have requirements over and beyond this then I am not sure of the best way to proceed.

UnRAID will show as unformatted if it cannot mount your drive, it does not mean the data is necessarily lost. If you started reiserfsck --rebuild-tree then until it completes you will not normally be able to mount the drive which would explain what you are seeing.

It looks like that drive was using NTFS format? If so, the built-in NTFS support is limited to drives of 2TB or less (and read-only access). The answer is to load the ntfs-3g package which supports larger drives and also write access for NTFS. There have been many forum posts about where to get this (I do not have the details to hand). I have requested in the past that this be included in the standard unRAID build, but so far this has not happened.

Yes. I have done something similar to that myself in the past. You do not mention how you are going to move the files. Note that if you do at the Linux level via a telnet session you are likely to need to run the newperms command afterwards against the target disk as moving files at the Linux level is likely to mess up file permissions. If you are moving them via the network shares then this step is not needed, but it is likely to be much slower.

Did you pre-clear the disk before trying to add it to the array? If you did not then the pre-clear will happen at the point you try and add the disk and while the pre-clear us running (which can take hours with a large disk) the array will not be usable. Running the pre-clear script against the disk before adding reduces the downtime to seconds, and also it carries out a full health-check of the disk as you do not want to add a disk that is not in prefect working order.

Perhaps you can provide some screen shots to illustrate your problem? One I would suggest are: - Main screen showing drives allocated - Settings->Share Settings - Shares->one of the shares showing the problems

If the partition is set up as an DOS style partition table and is an Extended partition rather than a primary partition, then the partition number in Linux will be 5. Partition numbers 1 to 4 are reserved for the primary partitions, and 5 upwards for partitions within an extended partition. You can use fdisk under Linux to see the current partition settings (make sure you do not write out a change).

Unless you are using only a few drives (and the free version of unRAID) then only option #1 is viable as your unRAID license is tied to the GUID of your USB drive. You would need a new license to use a different USB drive.

That will because unRAID can emulate one missing disk using the parity disk and the remaining data disks. However that means you have no redundancy left, so if a second disk fails before you have recovered the current bad disk this will no longer be true so you want to recover this 'bad' disk as soon as you can.

It was mentioned that you can control in the settings for each share what disks they are allowed to be on. What may not have been clear was that any folder you put at the top level on any of the disk?? type shares will automatically show up as a user share (assuming that you have user shares enabled).

It is much quicker to run it via a telnet session on /mnt/disk2, and that would be the approach I would recommend. Running it via the GUI will achieve the same effect in the end but take much longer as it will be run against all disks.

You need to run the newperms command on the lost+found folder before you will be able to access it via the network. The reiserfsck command will almost certainly have created it and all the files it contains as owned by 'root'.

Isn't that what I said (the username needs to all be lowercase)

That looks correct. it is quite normal to have to run with --rebuild-tree after having run with --rebuild-sb.

I seem to vaguely remember that you can have a problem if the username used is not all lower case at the Linux level?