Could someone help me with ReiserFS issue?

[NLS]

I am facing some problems related to unRAID's ReiserFS volumes, but not in unRAID.

My unRAID is currently off-line and I need to move at least some of my data to NTFS since I need to use them.

 

The problem is that though I managed to see most of my disks both using a Linux live CD and a Linux virtual machine (I use VirtualBox btw. and have set it to see my physical disks), three (probably two, because the third is parity), cannot be mounted.

 

Unfortunately my unRAID USB is not booting in my new motherboard and I don't have time to troubleshoot this first (also half of my unRAID disks are not unRAID any more so my old array will be invalid), that is why I am using full Linux distros. The virtual machine is Mint and the Live CD is Ubuntu.

 

Here is what happens when I mount the three "problematic" volumes:

 

Two of them (which I suspect are data disks that is why they have the same error), one 750GB and one 320GB, show in "computer" in Linux desktop and when I click to mount them, I get "no mount object for mounted object" and the disk is removed from my "computer" window.

 

The third disk (which I suspect is the parity that is why it's the only with this error), 750GB, shows in "computer" in Linux desktop and when I click to mount it, I get "unable to mount volume, operation not supported" and the icon is NOT removed from the window. I suspect this error message suggests there is no filesystem on that disk, so it's probably the parity.

 

So... Since my knowledge on linux ends here (ok it goes a little further, I could try and mount the disks from console), what is my next step to recover data from my two ReiserFS disks?

 

Note: It's not a bus issue, because I moved the two "failing" disks to the buses used by two working ReiserFS disks and the error "shifted" along (while the two working remained working in their new position).

 

Same errors happen in Live Ubuntu CD and in Mint virtual machine.

 

My two data disks are FILLED with data.

 

What should I try next?

I have no idea of FS/mount troubleshooting tools in Linux.

 

PLEASE help?

 

 

[limetech]

Can you connect the reiserfs-formatted disks to a Windows computer and use this tool to copy your data off?

[NLS]

Thank you for replying Tom.

 

First I need to add something: Reiserfsck does NOT find any corruption!

(using the small disk for my recovery tests since I know for sure it's a data disk and it has the least precious data)

 

Now to your suggestion, YaReg fails to run.

Note that YaReg did NOT fail to run on this exact (Windows) system, before. So it's not some incompatibility issue or anything like that.

The problem could be that there are many ReiserFS disks on this windows system and ReiserFS might get confused.

I am going to try rfstools directly and see what happens, but to be honest if Linux itself cannot mount those disks, I doubt rfstools would do better.

 

Will report back after (re)testing rfstools.

 

In the meantime, any other idea, welcome.

 

 

[NLS]

Well I may have good news. I tried mounting the disk using the console and it seems to work... I wonder what Ubuntu (and Mint - which is again Ubuntu) "desktop" does different than its own console, that fails...

 

Will get back if I have a success story.

 

 

[NLS]

Another thing to add (that COULD be related to unRAID's side of the story), is that the mount point I manually created, didn't give me access when not in superuser access. I had to "777" the whole mountpoint to get to read the content's in Mint's desktop.

 

Could this be related to unRAID having for some reason some weird security set on the whole volume? Is it possible?

 

 

[NLS]

Started copying off those disks.

 

Indeed the issue was the same with both problematic disks. The volumes were fully "hidden".

I had to manually mount them, 777 them and then I could read them fine.

In fact I rebooted and after the attribute changes, the disk was auto-mounted by Linux desktop fine.

 

So the question remains... Something in my unRAID settings had those two disks (and just those two) "hidden" as volumes? (and not just the folderss in them)

 

Is this considered a bug or just a side-effect of a feature? (trying to think what I may have set on those disks when I was in unRAID) I know both had one folder that was hidden as a share (one disk was full of this folder but the other had two folders where the second one was not hidden). I also know that another disk that had a few root folders (as shares) where one was hidden also, did not effect in the failure that happened with the two disks.

 

Anyway, might be useful for someone to know in the future.

 

 

[limetech]

You just don't understand *nix permissions.

[NLS]

Maybe so.

 

I still don't see the connection of hiding a volume to hiding a folder.

I did have my disk shares hidden in my unRAID, but that would possibly mean that ALL my unRAID disks when mounted on another system would be set as hidden. Not two of them.

 

Anyway thanks for the help Tom.

 

 

[Joe L.]

Maybe so.

 

I still don't see the connection of hiding a volume to hiding a folder.

I did have my disk shares hidden in my unRAID, but that would possibly mean that ALL my unRAID disks when mounted on another system would be set as hidden. Not two of them.

 

Anyway thanks for the help Tom.

 

 

There are multiple type of permissions involved, and it seems you are not clear on how they all work.

 

First, the "hiding" of disk shares on the LAN, that has absolutely nothing to do with unix permissions reading files, or getting a listing of files in a directory.

 

LAN shares are controlled by the SAMBA process.  To be shared by SAMBA, the directories and MUST be readable and searchable by SAMBA's user ID on the unRAID server.  (Those are two separate permissions)  On an unRAID server, the SAMBA process is invoked by "root" (user-ID = 0) so it has permission to read anything.  On most other *nix machines, the SAMBA process has its own user-ID for security purposes. Otherwise, anybody could read anyone's files.

 

Next, there is the permissions involved on the directory used for a mount-point.  It must be writeable by the ID performing the "mount" command in order for the "mount" to succeed.  That is why you needed to do a "sudo mount."  For the duration of the "mount" command you were made to look as the super-user and had an effective user-ID of 0, so the mount succeeded.

 

Once you mounted the unRAID file system on the other ubunto system you were returned back to a normal user-ID with your own set of permissions.  To be able to list files of a mounted file system you need to be in the same group of users (and you probably are not) or have the "other" permission on the mount-point set to be both readable and searchable.

 

Since the files and folders on unRAID are owned by root, unless you set the "other" permissions (For those not the owner, and not in the same group) you would not be able to traverse to them to list them. 

 

So... You have

 

Permissions on the "mount point"  You must have permission to write to it to use it as a mount point.

Permissions on the directories in the path to the mount-point.  To be used as part of a path, you must have "execute" permission on the directory.  To list them, you must have "read" permission.

Permissions on the mounted file-system directories leading to your files. To be used as part of a path, you must have "execute" permission on the directory.  To list them, you must have "read" permission.

Permissions on the files themselves.  To play them, you must have "read" permission.

 

None of those are the permissions on the LAN... those being set up and managed by the SAMBA programs in a whole separate configuration file (or files)  These are layered on top of the unix file-system permissions.

 

When you set the permissions on the mounted file system to all be "777" you gave read, write, and execute permission to the owner of the files and directories, those in the same group as the owner, and anyone else on the server (three sets of permissions)  At that point, since you gave permissions to anybody, you could as a normal user on ubuntu, read and write your mounted unRAID file-system.

 

These pages will give you an overview of just what "777" represents:

http://www.library.yale.edu/wsg/docs/permissions/

and here http://www.zzee.com/solutions/unix-permissions.shtml

and here: http://www.perlfect.com/articles/chmod.shtml

 

I'll repeat what Tom said, you need to understand *nix permissions to use an unRAID file-system on another server. On a shared server you would NEVER give anyone else the ability to read/write/delete/rename your files and folders as you did.  On a server you control, you can do as you please, just don't open up access to the world, or your files will be at risk.

Joe L.

[NLS]

I am aware of what 777 does.

 

Thanks for clearing the other details though (about the mount point, I know the rest in fact). Very informative.

 

To be honest, I am still not sure why two disks (not talking about folders) had different permissions when mounted, than my other six (all part of the same unRAID array). Maybe the explanation is somewhere in your post, but being sleepless for more hours than normal, I will give it a second read tomorrow.

 

I do understand the implications of changing the permissions, esp. on a shared server. I did what I did in my personal machine and just for migration reasons (RFS to NTFS). I will have Windows reset the proper security attributes for my needs anyway. Now if/when unRAID gets back the data (when I resolve my issues), I am sure it will again reset everything as unRAID "sees" fit.

 

PS. Note that Tom, wrote "You just don't understand *nix permissions.", not "you need to understand *nix permissions to use an unRAID file-system on another server". Just mentioning.

 

Thank you again both of you.