denied permission when copying files and folders

I have experienced the same problem on some servers, and have not yet heard of a solution (see my thread at: http://discussions.apple.com/thread.jspa?threadID=1530437&tstart=0). It appears to be a Finder issue - not a true permissions issue.

Oddly enough, I am not experiencing the problem with the W2K server that I am using at the moment.

The only solutions seem to be:

1) The command line (yes - I know you want to avoid it, but it is free, and it isn't that hard to learn, and the control it gives you is great).

2) muCommander (as suggested by someone in that thread).

Keith,

Yep, undoubtedly shadows of the disk error(s) you had. In this, things are cut and dried. You ran a command that sets the permissions for every file to allow everyone to read them. That command runs successfully. And yet, you still see it as "No Access," and cannot copy it. Not good. Please tell me that you have backups of these files, somewhere(?)!

I have two suggestions:

Suggestion 1) Log into an admin account on one of your Leopard machines, and mount the old drive remotely. Select the drive on your Desktop, and press Command-I to open a Getinfo window for it. Unlock the padlock at the bottom of the Getinfo window, and enable the option to "Ignore permissions" for the volume. Attempt to copy some of the files that appear as "No Access."

Suggestion 2) Enable the "root" account on one of your Leopard machines, then log in as root. Mount the old RAID remotely, then attempt to copy just some of those files that are listed as "No Access." Don't just go straight for a copy of everything, but see what can be done with just a few files.

The reason we're going to use the "root" account in this is to side-step the issue of permissions altogether. At this point, we just want to get those files copied! If some cannot be copied even using the root account, we want to copy as many as we can intact. To this end, you may have to dig into the sub-directories and copy things slowly, until you have discovered which files can be successfully copied, and which ones are totally trashed.

In the end, that old RAID volume should be reformatted (erased). If there are files that you cannot copy from it, even from the root account, and those files are not backed up somewhere else, you might want to consider something like Data Rescue for file recovery.

Scott

Does the copy command work at all though? If it does - it is not a permissions issue. If it does not, then there will be something more to look at.

The copy command can use wildcards and do thousands of files in one hit too. It will be faster than Finder in most situations.

But first, I would try to find one file that does not copy successfully and then use Terminal to copy it. That will verify that the diagnosis is correct.

I can then help you to construct a single command or sequence of commands that will transfer all of the files easily.

Cheers,

Rodney

Keith,

Wait! Before you go any further with any of the suggestions here (so far), we really need to know more than you have given us, if you are to get truly informed advice.

You are attempting to copy files from a RAID device connected directly to your "server," to an NAS device somewhere else on the network. OK, from where? Logged into said server? Running what OS? What OS was used to create the RAID array, then populate the RAID device with files and folder?

Have you attempted to copy files from the RAID array to the server's boot volume? Were you successful?

On the face of it, this sounds like a problem with ownership, not permissions. This is common, and would even make a lot of sense if you recently migrated to Leopard (in this case, it might actually be "normal"). That said, problems like these are easily correctible, but I will warn you that in the end, Terminal will probably be required.

This need not be arduous (using Terminal). Given some basic information from you, I can probably provide a single command that you can simply copy and paste in order to correct the entire problem. For good.

Scott

Keith,

First, let's clear any confusion by labeling these drives as "old" and "new." It doesn't matter that they are both RAID volumes, just that they each represent as single volume. And, when I say "logged into the server," I mean that you are sitting right there, physically at that machine, logged into whatever account you have on that machine. By "copying files to the boot volume," I mean copying files from the attached (old!) drive to that machine's internal startup disk, perhaps to some location in your HOME folder. So, given this, here's what we need to know:

1) What version of OS X is currently in place on the "server?" Yes, I know this is just an OS X client, but it is serving files, so we'll label it the "server." You mention that all the other machines are running 10.5, but you neglect to mention what version of OS X is running on this "server." It could be critical.

2) When the old drive was populated with the files that you are attempting to copy, what version of OS X was in place? Was this the version that was in place when you first began using the drive? If not, what version of OS X was in place at that time?

3) I'll ask the question again: When you are attempting to copy files, where and how are you logged in? Physically sitting at and logged into the "server," or sitting at some other computer on the network, with the server's "share" mounted remotely?

FYI: I am guessing that you also have 10.5 on the "server," but that the "old" drive was used mostly within Tiger, until recently. If this is the case, your current difficulties are undoubtedly caused by inconsistencies in group ownership for at least some of the directories you are trying to copy. Even with these discrepancies in group ownership (rooted in some differences between Tiger and Leopard), your ability to read and/or copy files would not be prevented, but you are attempting to copy files and directories wholesale, which brings additional complications. This more complicated action would be affected by the discrepancies in group ownership.

And, it is this discrepancy in group ownership that I propose you change, if in fact we can determine it exists. To that end, I need the answers to the questions above.

Scott

Keith,

OK! Yes, this is just the information I need. The most important factoid here is that the "server" is still running Tiger.

You see, the "traditional" paradigm used in 'NIXes regarding default groups for users is to place everyone in a catch-all "staff" group. In most cases, under this paradigm, files and folders are consequently created with a group ownership of "staff." Now, it is also necessary to note here that files "inherit" their group ownership, at the time they are created, by the parent folder in which they are being created. Got it so far?

So, when creating a file in a given folder, the OS will attempt to create that file with a group ownership based on the parent folder. The user creating the file, meanwhile, must be a member of that group! Under the traditional UNIX paradigm of having everyone in the "staff" group, this potential roadblock is removed (again, in most cases).

With the advent of Panther, however, OS X deviated from this paradigm. In Panther and Tiger, users were created with unique default groups! Each user was placed in their own group, said group named according to the user's short name. So, when a user "fred" creates a file (or folder!) in Tiger, the file is owned by "fred," with a group ownership of "fred."

Well, Leopard returns to the old paradigm, (potentially) throwing the whole thing into disarray. It certainly has in your case.

Without going into the intricate dance that occurs when you attempt to transfer entire directory hierarchies with various group ownerships, some (most) of which do not even exist on the machine into which you are logged, I'll just state that this is what's messing things up for you.

Hmmm. Log in directly, as an admin user, on the Tiger "server." The "old" RAID array is connected directly to this machine, yes? Please copy and paste the two lines below into a Terminal window, one line at a time followed by a <RETURN>:

<pre style="overflow:auto; font-family: 'Monaco'; font-size: 10px">id
ls -ale /Volumes</pre>

Please post the entire results of these commands, including the commands themselves. This will give me the info I need to fashion commands that you can copy and paste to correct the problems (we hope).

Some background info: While Tiger did/does not place users into the "staff" group, that group still exists in Tiger. So, we can legitimately change the group ownership of any existing files to "staff," even in Tiger. That is what I propose we do, and we can do so "wholesale" in a single command which will apply to the entire contents of that external volume (it doesn't matter that it is a RAID array; it is just a volume for our purposes here). This may cause problems for any users on that Tiger machine, but we can fix that simply by placing all of your users that may exist on that Tiger machine into the group "staff." This will not change their Tiger "default" group, merely place them into an additional one (users can belong to any number of groups).

Scott

Keith,

OK, everything is clear-cut. Notice that the results from the first command indicate that your "GID" is listed as "501 (keiththirgood)." This is what causes the problem, at least for copying files from another machine where your "GID" will be "20 (staff)," and the "keiththirgood" group doesn't even exist. No problem, we'll just change this.

Again, just copy and paste the two lines below, one line at a time followed by a <RETURN>:

<pre style="overflow:auto; font-family: 'Monaco'; font-size: 10px">sudo chown -R keiththirgood:staff /Volumes/Data\ RAID
sudo chmod -R a+r,X /Volumes/Data RAID</pre>

When you run the first command, you will be asked for your admin password. Enter it (it will not be echoed!), then again press <RETURN>. If you run the second command within 5 minutes, your password will not be necessary for that one.

You should now be able to able to log into any of the other machines, running Leopard, and copy the files successfully.

Scott

Keith,

Well, I'm not sure why you would get any errors on the first command (we'll deal with that in a bit), but the error you got on the second is my fault. Let's try that one again, this time the right way:

<pre style="overflow:auto; font-family: 'Monaco'; font-size: 10px">sudo chmod -R a+rX /Volumes/Data\ RAID</pre>

Now, we must figure out why you are getting errors with the "chown" command. This shouldn't happen, ever, given the way we have run it. Can you confirm for me that the "Data RAID" volume is actually an HFS+ formatted ("Mac OS Extended") volume? You can check this using Disk Utility. Just select the "Data RAID" volume in the list at the left side of the Disk Utility window, and the volume information will be displayed at the bottom.

If the Data RAID volume is HFS+, there could be some problem with the files listed in the error messages. This could be either directory errors, perhaps caused by the failed copy attempt you have made, or it could be the "immutable bit" set for those files. Since you'll have Disk Utility open anyway, go ahead and switch to its "First Aid" tab with the "Data RAID" volume selected, then click "Verify Disk." If any errors are found, use the "Repair" function.

Then, go back to Terminal. We're going to take care of the possibility that the "immutable bit" is set for any of the files. Then, we're going to run the "chown" command again, but this time we'll separate out the "ownership" and "group ownership" elements in order to isolate any potential problems. Copy and paste the following line, followed by a <RETURN>:

<pre style="overflow:auto; font-family: 'Monaco'; font-size: 10px">sudo chflags -R nouchg /Volumes/Data\ RAID</pre>

Note: The "chmod" command listed at the top of this post will also fail for any files where the "immutable bit" has been set. If this occurs, you'll need to run the above command (the "chflags" command) first, then attempt the "chmod" command again.

Now we'll change the ownership, using two commands instead of one. Copy and paste the following two lines, one line at a time followed by a <RETURN>:

<pre style="overflow:auto; font-family: 'Monaco'; font-size: 10px">sudo chown -R keiththirgood /Volumes/Data\ RAID
sudo chgrp -R staff /Volumes/Data\ RAID</pre>

Let me know how this goes.

Scott