On Sat November 4 2006 9:39 pm, John Andersen wrote:

On Saturday 04 November 2006 20:34, Richard wrote:

...

I ready for the big head slap with a following, "well, duh..." I am trying to remove files, .rpm files as it happens from a drive. Even as root, it is refused, "Operation not permitted". I even looked up and tried shred, which also gives an error message. Chmod will not allow changing any file permissions or ownership...I only thought if I could change one of those that might make it more amenable to deletion. Is there maybe something about the drive itself that might be making it un-writable/deletable. I would certainly consider writing a new file system to the drive as I want nothing on it. I took a short look at hdparm and elected to ask here before doing anything I might later regret...and then come back here to try to fix.

Thanks for any suggestions.

Richard

Might be a corruption problem. Several have mentioned on these lists that a reiserfs partition that gets boogered and needs a reiserffchk usually drops into read-only mode, if not for the whole drive than some significant part of it.

So unmount it (boot with rescue cd if necessary) and run a check on it.

Thanks. Just did that and it reports no superblock. I ran the reiserfsck and applied fixes it suggested, but now most recent message is, "Bad root block 0. (--rebuild-tree did not complete)". It is ok with me to re-write the filesystem to the drive if necessary to get a usable drive back, as I am not concerned about losing any of this data. Thanks again for your assistance. Richard

<snip>

...

...

Might be a corruption problem. Several have mentioned on these lists that a reiserfs partition that gets boogered and needs a reiserffchk usually drops into read-only mode, if not for the whole drive than some significant part of it.

So unmount it (boot with rescue cd if necessary) and run a check on it.

Thanks. Just did that and it reports no superblock. I ran the reiserfsck and applied fixes it suggested, but now most recent message is, "Bad root block 0. (--rebuild-tree did not complete)".

It is ok with me to re-write the filesystem to the drive if necessary to get a usable drive back, as I am not concerned about losing any of this data.

Thanks again for your assistance.

Richard

Had the same problem only a couple of weeks ago.

I followed the suggestion to run 'reiserfsck --rebuild-tree' and it cleared up the trouble on the first run and without any loss of data. Your mileage may vary of course.

Cheers. <snip>

...and it has. Just finished running that and it reports "Could not find a hash in use. Using "r5" Selected hash ("r5") does not match to the hash set in the super block (not set). "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 38760402 Leaves among those 0 Objectids found 2" Following some other suggestions after this I ran debugreiserfs and got a series of information and messages which included that the filesystem was not clean and that FATAL corruptions existed. There were also directions to move, offset, zero the superblock... none of which I am about to do, having only the vaguest notion of what this is all about. Vague, uh, I know I have read about this somewhere so it is not total greek to me, but pretty close. What would be the best way to simply start the disk over? That is, in windows-speak, re-format the drive? I assume I could do that by re-starting the installation from the CD/DVD's, and leaving all partitions alone except the one I want to re-do, but it also seems there must be a more direct way, thus I had looked at man hdparm, but it did not seem particularly direct to doing this. I am sure I have missed something. Richard

On Sat November 4 2006 11:38 pm, Basil Chupin wrote:

Richard wrote:

...

<snip>

...

...

...

Might be a corruption problem. Several have mentioned on these lists that a reiserfs partition that gets boogered and needs a reiserffchk usually drops into read-only mode, if not for the whole drive than some significant part of it.

So unmount it (boot with rescue cd if necessary) and run a check on it.

Thanks. Just did that and it reports no superblock. I ran the reiserfsck and applied fixes it suggested, but now most recent message is, "Bad root block 0. (--rebuild-tree did not complete)".

It is ok with me to re-write the filesystem to the drive if necessary to get a usable drive back, as I am not concerned about losing any of this data.

Thanks again for your assistance.

Richard

Had the same problem only a couple of weeks ago.

I followed the suggestion to run 'reiserfsck --rebuild-tree' and it cleared up the trouble on the first run and without any loss of data. Your mileage may vary of course.

Cheers.

<snip>

...and it has. Just finished running that and it reports "Could not find a hash in use. Using "r5" Selected hash ("r5") does not match to the hash set in the super block (not set). "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 38760402 Leaves among those 0 Objectids found 2"

[pruned]

I should have mentioned in the first response that I was told that it may take a number of attempts running --rebuild-tree to get the problem repaired. In my case it only took the one run- which is why I said "on the first run". Try running --rebuild again (and again.....).

However I see from what you then wrote is that you don't really care about the data and happy to reformat the partition. If so you could use fdisk or cfdisk but I suggest that the easiest way would probably be to:

Yast2 Control Centre>System>Partitioner; select the damaged partition then Edit>Format in the filesystem of your choice.

Cheers.

Thanks. I think that will be the "final solution" for me. fdisk was the command I was really trying to recall when I was checking on hdparm. Ok, I am getting old, and dotty. Why I never think to go straight thru Yast amazes me. Done already, and very simple, and can now write to and use the disk. Thanks again. Richard

Richard wrote:

<snip>

...

...

...

Might be a corruption problem. Several have mentioned on these lists that a reiserfs partition that gets boogered and needs a reiserffchk usually drops into read-only mode, if not for the whole drive than some significant part of it.

So unmount it (boot with rescue cd if necessary) and run a check on it.

Thanks. Just did that and it reports no superblock. I ran the reiserfsck and applied fixes it suggested, but now most recent message is, "Bad root block 0. (--rebuild-tree did not complete)".

It is ok with me to re-write the filesystem to the drive if necessary to get a usable drive back, as I am not concerned about losing any of this data.

Thanks again for your assistance.

Richard

Had the same problem only a couple of weeks ago.

I followed the suggestion to run 'reiserfsck --rebuild-tree' and it cleared up the trouble on the first run and without any loss of data. Your mileage may vary of course.

Cheers.

<snip>

...and it has. Just finished running that and it reports "Could not find a hash in use. Using "r5" Selected hash ("r5") does not match to the hash set in the super block (not set). "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 38760402 Leaves among those 0 Objectids found 2"

Following some other suggestions after this I ran debugreiserfs and got a series of information and messages which included that the filesystem was not clean and that FATAL corruptions existed. There were also directions to move, offset, zero the superblock... none of which I am about to do, having only the vaguest notion of what this is all about. Vague, uh, I know I have read about this somewhere so it is not total greek to me, but pretty close.

What would be the best way to simply start the disk over? That is, in windows-speak, re-format the drive? I assume I could do that by re-starting the installation from the CD/DVD's, and leaving all partitions alone except the one I want to re-do, but it also seems there must be a more direct way, thus I had looked at man hdparm, but it did not seem particularly direct to doing this. I am sure I have missed something.

Richard

There is a really neat tool to completely wipe out a partition table called SLATE. Try a google for it and if you can't find it let me know and I'll set it up so you can get it off my website. Ken

Anders Johansson wrote:

On Sunday 05 November 2006 19:02, ken wrote:

...

There is a really neat tool to completely wipe out a partition table called SLATE.

Why would you want to wipe it out?

parted /dev/<your device> mklabel msdos

should create a fresh, empty partition table for you

If you really feel you have to wipe it out

dd if=/dev/zero of=/dev/<your disk> bs=1 count=512

will wipe out the MBR and the partition table. For just the partition table, make it

dd if=/dev/zero of=/dev/<your disk> bs=1 count=64 skip=446

But there usually is no need. In the installer, deleting and recreating the partitions is more than enough

Because it's quick, easy and does a very complete wipe. As I recall there are usually two copy's of the partition table (at least there were in DOS) and this neat little tool does away with the whole shebang. Then one can start with a totally clean drive. Ken

Anders Johansson wrote:

parted does a very thorough job, it is one of the best - if not the best - partitioning tools there are. And the YaST partitioner uses parted to do its job.

Good, but not quite the best - it refuses to touch my /dev/ida/* devices (Compaq SMART array). I don't mind too much, but what did YaST use prior to parted? Per Jessen, Zurich -- http://www.spamchek.com/ - managed email security. Starting at SFr5/month/user.

Anders Johansson wrote:

...

Good, but not quite the best - it refuses to touch my /dev/ida/* devices (Compaq SMART array). I don't mind too much, but what did YaST use prior to parted?

I don't know, it's been using parted for a long time

I see your mail on opensuse-factory, but you don't mention the error message. When you get this in YaST, what do you see in y2log, what is the actual error message from parted?

Uh, I think I forgot I'd asked about it - I get a popup window during installation, so it would also be in the y2log. I think it says "Can't read the partition table of /dev/ida/*" and something about how I can't edit, but I can use the partitions. I assumed parted was something new in 10.2, coz it worked fine in 10.0 and 10.1. Per Jessen, Zurich -- http://www.spamchek.com/ - managed email security. Starting at SFr5/month/user.

On Sunday 05 November 2006 11:22 am, Richard wrote: <trimmed>

It was mounted -rw--------- with ownerships to root only. There is also "System Volume Information" directory that I do not remember creating there. OTOH, most files are dated 08-2005, and I remember very little of anything else from that far back either.

Richard

My first guess would be this partition you are talking about is not a Linux Native partition. This "System Volume Information" directory you are talking about is often found on FAT32 partitions. (Not sure if NTFS creates them as well) Moreover, if this partition has a FAT32 File System, how about including the umask=0000 option while mounting this partition to give read-write-execute access to all files and folders on this partition? Regards, Amit. -- Remember fellas, what we do in life echoes in eternity!

On Sat November 4 2006 10:41 pm, Randall R Schulz wrote:

Richard,

On Saturday 04 November 2006 21:34, Richard wrote:

...

I ready for the big head slap with a following, "well, duh..." I am trying to remove files, .rpm files as it happens from a drive. Even as root, it is refused, "Operation not permitted". I even looked up and tried shred, which also gives an error message. Chmod will not allow changing any file permissions or ownership...I only thought if I could change one of those that might make it more amenable to deletion. Is there maybe something about the drive itself that might be making it un-writable/deletable. I would certainly consider writing a new file system to the drive as I want nothing on it. I took a short look at hdparm and elected to ask here before doing anything I might later regret...and then come back here to try to fix.

One of the perpetually confusing things about the Unix file system and its permissions scheme is that the ability to delete a file has nothing to do with the file's permissions, at least not as far as the kernel is concerned (more later on the weasel-words and an actual exception).

The ability to create a file or delete a file is governed by the directory in which the file exists or is to be created. The required permissions include both execute and write. The seeming exception is that the "rm" will ask you if you want to delete a file for which you do not have write permissions. But the actual ability to delete a file, (once you say "yes" to the "rm: remove write-protected regular file `fileName'?" confirmation question) still comes down to you having write and execute permission on the directory in which the file resides.

Nor does it matter who owns the file, but there's an exception to that, too. Look at the modes on /tmp (assuming a conventional setup):

% ll -d /tmp drwxrwxrwt 64 root root 32768 2006-11-04 22:33 /tmp/

Note the 't' bit. This stands for "sticky" (and in its original meaning had nothing to do with directories, but that's irrelevant here). When a directory has its sticky bit set, only the owner of a file may remove it, still subject to the other permissions check on the directory itself. This feature is used by directories such as /tmp or "drop folders" where it's desired that anyone be able to create files but not interfere with each other's use of such a shared diretory.

Note, too, that only the owner of a file (and root) may change a file's (or directory's) mode. And only root may change a file's or directory's owner. Non-root users may neither take ownership of files they don't own nor give away files they do own.

...

Thanks for any suggestions.

Take that information and verify that the existing permission allow you to remove the files in question.

...

Richard

Randall Schulz

Randall: this is clearly one of the best and most direct explanations of linux permissions I have seen. Thank you. This will go in Linuxinfo save box, where I keep stuff from this list for future reference. I was aware that I could probably not get away with changing any of those features, but tried to I guess just to see if I could do something/anything to the files. Nada. I suppose what I found was that I could not access them at all, and could not even add files or directories. What with M Harris, Basil, and John have suggested, I think it is clear the fs is corrupted, and with not being able to fix with reiser tools, I suspect hopelessly so. As I suggested before, saving the data is not an interest for me. .rpm files there were a download for use with an installation of SuSE 9.3, or maybe earlier, so not of current interest or use to me. At this point, I think the best course is to "re-format" the drive. I suppose I could use the partitioning tools that came with the drive, then re-install a linux fs. I suspect there may be a more direct way also. Somehow, as I follow threads on this list in the past there often crop up some esoteric command, simple, direct, easy, just un-common enough not to be immediately at fingertip. Thanks for your concise permissions description. I may even "memorize" it for new potential users I talk to to explain it all to them. Richard