gubbgnutten

I would do a new config. ...either with parity added (and not check "parity is valid"), let parity sync and enjoy some protection. ...or without parity added (no worse off than with the current invalid parity) and enjoy the speed benefits while moving data around. Right now it seems like you are getting the downsides of both options - slowness and no protection against disk failure.

Parity does not sound valid to me... A correcting parity check will be quite slow due to all corrections.

If you open a command prompt and run ping tower does it show the expected address?

Sorry, nothing like that is built into unRAID. You mention "recover [your] data", is your data not available now?

The user one is the regular root of user shares, with contents from both cache and disks, while user0 excludes the cache. The latter is used by the mover script when moving content from the cache to the array.

Impossible to say if a clean install would fix your problems since we have no idea what they are. If your son's homework is finished, consider grabbing and posting diagnostics now. Any messages on the console?

Did you check the serial number of the red? Some sellers have harvested drives from external mybook drives and sold them as reds... Some users have had problems with such harvested drives being smaller.

Check if you can simply disable UEFI booting. I tend to do that on my unRAID servers to reduce confusion and only have the USB stick listed once.

Oh, I'm sure. The Wikipedia page on Binary prefix could be an interesting read for you, with examples, history and inconsistencies. Quite a mess.

What you want is a setting to switch between base-2 and base-10 units. Maybe rephrase the request?

When you keep talking about "usable", it sounds like you believe that the reason Windows is showing about 2.7TB for 3TB disk is that the rest of the space exists but is unusable for some reason... The 3TB drives are 3TB, not 3TiB.

I know about the concept. But that is not how everyone else counts bytes. Unraid is the only system I have ever seen reporting bytes like this. You have never seen a modern version of Mac OS? In any case, look at it from the perspective of a user of unRAID. The user buys a 3TB disk and sees 3TB in the user interface instead of a confusing lower number that does not make any sense, that surely can not be a problem? Edit: Perfect example by the way, thank you! You got the 800GB by subtracting 8.2 from 9.0 (TB), right? But if you insist on using 1024 rather than 1000 as base, that 0.8 in one unit does not translate to 800 in the smaller one...

Still, giving a random (possibly hostile) user write access to /boot would be a really really bad idea from a security point of view. Lots of potential for mischief.

Maybe look into running a VM to provide remote shell access and whatever you need rather than messing with the base system?

And you are absolutely sure that you set the time in BIOS to UTC time and then the appropriate time zone in unRAID?

Except that user eebrains would normally not be able to log in...

What jedimstr posted in a thread you should be familiar with works for me.

Why? Well, your attitude would be one darn good reason Except that there was no case of "deliberately withhold information" here, so the question does not really make sense. If you are in need of spoon feeding but only get regular help, try asking for it nicely rather than attacking people helping you. The results might surprise you!

Check /etc/profile, you'll find that the contents are not what you expect. From what I can see, you are redirecting the alias output to /etc/profile rather than writing the alias line to it. Consider the difference between the following two commands: alias size='du -sh --time'>>/etc/profile echo "alias size='du -sh --time'">>/etc/profile Edit: Really, check /etc/profile after making changes to it. Make sure you got your quotes/escaping correct if you are appending to it! Another option is to write the aliases in a separate properly encoded text file with appropriate line endings stored on the flash drive and just append the contents of that one instead. cat /boot/aliases.txt >> /etc/profile

If you are holding down the power button the system won't shut down in an orderly fashion, that only happens after a quick press of the power button. Holding is rude!

That should do it. Granted, I did not look for other potential problems in the diagnostics, but ReiserFS and timeouts are old buddies of mine My switch from ReiserFS to XFS was time consuming but painless as I did it while adding a new disk. 1. Pre-cleared my new disk 2. Added the new disk to the array and let unRAID format it 3. Copied all files from one ReiserFS disk to the empty XFS disk 4. Verified checksums of all written files 5. Changed file system of the ReiserFS disk and let unRAID format it 6. GOTO 3.

ReiserFS does not handle filled disk well at all, it gets really slow. The writes are probably timing out. Edit: Saw the diagnostics. Time outs and filled disks...

Are you uploading to CrashPlan's servers? In my experience backing up to CrashPlan’s servers is slow, at least from where I’m located. Backing up more or less incompressible data typically results in around 3Mb/s (less than 0.5MB/s) with low CPU usage, despite a 100Mb/s connection. The same backup set to a private CrashPlan install is way way faster. Same results for both my unRAID docker and regular PC installs. Not quite sure what speeds you are getting, typically B is used for byte and b for bit, but a 10 megabyte per second upload is … nonstandard.

No, they just allow applications to set up port forwarding all by themselves...

Yeah, the 640 and 640L are different beasts. Rocket and RocketRAID are different as well, allthough some cards have both designations printed on the PCB. HighPoint's naming schemes and revisions leave a bit to be desired... Not that it really matters, I wouldn't let any of those cards anywhere near my hardware.