unRAID Server Release 5.0-beta14 Available


limetech

Recommended Posts

Disk /dev/sda: 3000.6 GB, 3000615492608 bytes

255 heads, 63 sectors/track, 364804 cylinders, total 5860577134 sectors

 

5860577134 sectors * 512 bytes = 3000615492608 bytes.

 

From all signs, you have a brand new 3TB drive.

 

Now, it could be the disk controller or disk driver that limits the reported size, and the actual size may be greater...

but as far as unRAID is concerned, that is a 3TB drive, not a 4TB drive.

 

If you have more than one type of disk controller on your server, you might try the other and see if it still reports it as a 3TB drive.

 

Joe L.

Link to comment
  • Replies 496
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

No joy.  It wasn't running and when I restarted it I got this:

 

Jan 10 19:51:59 freenas emhttp: unRAID System Management Utility version 5.0-beta14
Jan 10 19:51:59 freenas emhttp: Copyright (C) 2005-2011, Lime Technology, LLC
Jan 10 19:51:59 freenas emhttp: Pro key detected, GUID: 0781-556B-3109-3213ECBXXXX
Jan 10 19:51:59 freenas kernel: mdcmd (35): spindown 2
Jan 10 19:52:00 freenas kernel: mdcmd (36): spindown 3
Jan 10 19:52:01 freenas emhttp: rdevName.22 not found
Jan 10 19:52:01 freenas emhttp: diskFsStatus.1 not found
Jan 10 19:52:01 freenas kernel: emhttp[17085]: segfault at 0 ip b754a760 sp bf9442b0 error 4 in libc-2.11.1.so[b74d1000+15c000]

 

This seems to be some great mystery of the universe.  Seems like a dozen of us suddenly started having this problem, but no answers exist.  rdevName.22 not found, but I don't know what that means and why it didn't happen for months and suddenly it starts happening.  I've disabled everything extra and still have the problem.  No one has ideas on how to fix this?

 

Test with a clean install.

 

Short of purchasing a new license to put on a new USB flash drive, what files can I delete (after making a copy of course) to bring me back to a stock install?  I disabled all plugins, auto installs, scripts, etc. already.

 

I just solved the same error on my system. Are you using ESET antivirus suite? The web scanner crashes emhttp on unraid. see http://lime-technology.com/forum/index.php?topic=18333.0

 

Wow I do use ESET, let me check this out thanks!

 

UPDATE: Many thanks this did solve the problem!

Link to comment

Just just upgraded from the trusty 4.7 to B14. I followed all the instructions to a T and ran the New Permissions. I had no users , no security setup in 4.7. But now I cannot edit some  files in my Media shares. Specifically files I uploaded via USB disk with Midnight Commander. I ca still edit files uploaded though the network.

 

I am desperate as I have been on this since yesterday and cannot see any obvious settings to change or add to allow me to delete or change name of files. The error message is "You need permission from TOWER\NOBODY to make that change"

 

I am working on a Win7 desktop and I added the name of the computer to USERS with no effect.

 

Please help me.

Link to comment

Just just upgraded from the trusty 4.7 to B14. I followed all the instructions to a T and ran the New Permissions. I had no users , no security setup in 4.7. But now I cannot edit some  files in my Media shares. Specifically files I uploaded via USB disk with Midnight Commander. I ca still edit files uploaded though the network.

 

I am desperate as I have been on this since yesterday and cannot see any obvious settings to change or add to allow me to delete or change name of files. The error message is "You need permission from TOWER\NOBODY to make that change"

 

I am working on a Win7 desktop and I added the name of the computer to USERS with no effect.

 

Please help me.

 

you probably need to login through telnet as root and update your file permissions to allow your user to write to those files. I would suspect that they are owned by nobody with permissions something like 644. So you need to chown them to your user, or update the permissions to 666.

 

Welcome to the bleeding edge....

 

whiteatom

Link to comment

Just just upgraded from the trusty 4.7 to B14. I followed all the instructions to a T and ran the New Permissions. I had no users , no security setup in 4.7. But now I cannot edit some  files in my Media shares. Specifically files I uploaded via USB disk with Midnight Commander. I ca still edit files uploaded though the network.

 

I am desperate as I have been on this since yesterday and cannot see any obvious settings to change or add to allow me to delete or change name of files. The error message is "You need permission from TOWER\NOBODY to make that change"

 

I am working on a Win7 desktop and I added the name of the computer to USERS with no effect.

 

Please help me.

Your issue is that when you telnet in and move files the ower:group get set to root:root.  Any files you move via "mc" will have to have the permissions corrected.

 

Also search on the forums, this has been discussed ad nauseum with a lot of people that have upgraded from 4.7 being  "upset" about it.  The fact is the permissions are now correct and you will have to set up your shares to how you want want it to be.  Do not try to connect to the server as root via windows and move files that will just screw stuff up.  Create an "admin" user through the unRAID webUI and use that as your "power user"

Link to comment

Thank you for your help. I must be really dumb and unlucky because I did search the forum and did not find this problem being discussed. Please link me or tell me how to correct my file permissions. If I create an "admin" user through unRaid, do I need to have a PW or leave it blank and still have access to editing files? I was real happy before all these improvements. If I downgrade back to 4.7 will I still have the problem with MC file transfer.

Link to comment

Thank you for your help. I must be really dumb and unlucky because I did search the forum and did not find this problem being discussed. Please link me or tell me how to correct my file permissions.

Here.  A google search on linux permissions will go a long way to explaining what is going on.

 

If I create an "admin" user through unRaid, do I need to have a PW or leave it blank and still have access to editing files?

Honestly not sure, why not try and find out.

 

I was real happy before all these improvements. If I downgrade back to 4.7 will I still have the problem with MC file transfer.

Ignorance is bliss in this case.  The root:root owner:group stuff of 4.7 annoyed some of use that know how permissions work.  5.0b goes a long way to correcting the issue.  If you downgrade to 4.7 the MC issues will go away and you will not run into these permissions "problems"

Link to comment

I understand that when I use MC and telnet the owner and group are root:root. When I use the web GUI the owner is NOBODY. The ROOT users can access and edit files in the ROOT group, i.e MC and telnet. The WebGUI on the other hand cannot edit the ROOT files. All that is very informative. How do I fix it permanently to correct this problem.

 

If I type in telnet chmod 666 myfile or mydir that would that solve this file and this directory problem. Instead should I use "chown users THE_ENTIRE_DIRECTORY_HERE" . THE_ENTIRE_DIRECTORY_HERE being my USB directory that I want to copy to the disk1.

 

Not sure what running "newperms /mnt/disk1" will do for me since I already ran the new Permissions applets when upgraded to 5B14. Or will it fixed all my permission problems by changing all ROOT to NOBODY. But my disk1 is already owned by NOBODY.

 

My problem is I assume that I am NOBODY when I used Windows to manage my files as opposed to ROOT when I used MC. How do I make NOBODY to grant me permission to edit my files.

 

Not really sure creating ADMIN user will do for me since it does not seem to have any permission assigned to it. Do I need to stop the array to do that?

 

Sorry about all this I have read this permission subject for the couple hours.

Link to comment

a chown -R nobody:users THE_DIRECTORY_HERE should fix it so that you can edit/change/etc the files from the windows machine again.

 

As for the "admin" user thing.  I was assuming you were moving files around in windows as the root user (i.e. logged in as root) which should have caused the same issues as you see from "mc"

Link to comment

Hopefully I fixed all hardware issues (cables) and rebuilt the data on a drive, but why is it that the 5.0 beta's indicates that no parity check is recorded and should be performed after a successful data rebuild with no errors?

 

I mean, the rebuild utilized all the "parity data" from the other "good" drives to build one drive, so if there are no errors after rebuild then the parity information should be fine, no?  To me, it doesn't make sense that v5 indicates no parity done but v4 does after such an operation.

 

Why is that?

Link to comment

I would have assumed that during the data rebuild process if there was a write error then that would be reported and the rebuild suspect.  I guess there is a very small possibility that even though a write may be successful, a subsequent read may fail; unlikely but the potential exists perhaps.

Link to comment

I would have assumed that during the data rebuild process if there was a write error then that would be reported and the rebuild suspect.  I guess there is a very small possibility that even though a write may be successful, a subsequent read may fail; unlikely but the potential exists perhaps.

Yes, a write error would take the parity disk off-line. It would be detected.  We are more concerned with a "write" that returns no error.

 

What is not checked is that you can read what was written.  That will not be known until either

A. The next parity check.

or

B. The next time a disk fails and, you find you cannot read back the parity disk block critical to that one file you must have.

 

Joe L.

Link to comment

log in and type:

df

You are running beta software.  It could be a display issue, or, you might be out of space.

 

i know i'm not out of space. I had anywhere between 50gb and 200gb free on each drive before the upgrade. Any quick way to set permissions across all drives?

 

UnRaid login: root
Linux 3.1.1-unRAID.
root@UnRaid:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              1953152    861920   1091232  45% /boot
/dev/md4             1953454928   1389928 1952065000   1% /mnt/disk4
/dev/md1             1953454928 1953454928         0 100% /mnt/disk1
/dev/hda1            316326412  89827712 226498700  29% /mnt/cache
/dev/md2             1953454928 1953454928         0 100% /mnt/disk2
/dev/md3             1953454928 1953454928         0 100% /mnt/disk3
shfs                 7813819712 5861754712 1952065000  76% /mnt/user0
shfs                 7813819712 5861754712 1952065000  76% /mnt/user
root@UnRaid:~# 

Link to comment

log in and type:

df

You are running beta software.  It could be a display issue, or, you might be out of space.

 

i know i'm not out of space. I had anywhere between 50gb and 200gb free on each drive before the upgrade. Any quick way to set permissions across all drives?

 

UnRaid login: root
Linux 3.1.1-unRAID.
root@UnRaid:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              1953152    861920   1091232  45% /boot
/dev/md4             1953454928   1389928 1952065000   1% /mnt/disk4
/dev/md1             1953454928 1953454928         0 100% /mnt/disk1
/dev/hda1            316326412  89827712 226498700  29% /mnt/cache
/dev/md2             1953454928 1953454928         0 100% /mnt/disk2
/dev/md3             1953454928 1953454928         0 100% /mnt/disk3
shfs                 7813819712 5861754712 1952065000  76% /mnt/user0
shfs                 7813819712 5861754712 1952065000  76% /mnt/user
root@UnRaid:~# 

The "df" command shows what is being reported by the operating system.  You have three disks that have no free space.
Link to comment

Trying again as my first 4TB was a dud out of the box, but so far, unRAID and the SM X7SPA mobo with the 4TB connected to on-board SATA port recognizes all 4TB and is currently building parity on it...

 

Crossing my fingers.


24 hours later, success!  Now another 24 hours just for the parity check.  Again, didn't I just do a parity build on the new parity drive, but now I must also do a parity check?  ???

 

After that, I will swap the previous 3TB parity drive in place of a 2TB drive, meaning yet another 48 hours of data rebuild and parity check.  Ugh.

Link to comment

Ya mean, to see if there are read errors since that's not checked during a parity/data rebuild as that only does a write op (which should report any write errors).

 

(sigh)  I realize that there is an infinitesimal chance that a drive may have a completely successful write op but fail during a read op, however remote that possibility may be.... but 25 years dealing with hundreds of drives, from the original 5.25" Winchester SCSI's to IDE and now SATA, I personally have not experienced such a failure; if a drive fails, it would definitely make it known during a write.

 

But for the purposes of unRAID, I understand its best to be safe than sorry...

Link to comment

So I began a data rebuild on a 3TB drive (which was the parity drive until it was just replaced with a 4TB drive) but the web GUI stopped responding, oh, around 2%.  unMenu still worked; telnet/command line still worked.  Usually, even if the web GUI appears to lock up, entries are still being made in the syslog or a least there would be a trail of errors before the crash, but this time the syslog was "clean" and remained stale and after 20 minutes of hoping unRAID would "unfreeze" I decided to reboot the box via command line.

 

After which, everything seems to be working fine so far and its now up to 8% and progressing... 38%...complete.


Now comes the final 24 hours for the parity sync... (sigh)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.