denied permission when copying files and folders

Keith,

Yeah!!! Terminal, or rather UNIX, is famously closed-mouth. The fact that you saw no apparent feedback is a good thing, and indicates that the commands were executed successfully.

You should be able to copy files without issue, now. Give it a try, from one of the machines running Leopard.

Scott

Keith,

Wow, you're really having some problems with this. They certainly aren't normal; probably caused the disk error you had. We changed the permissions to give everyone read access to every file on that volume. There's only one additional thing that comes to mind that would return a "everyone No Access" permission on any item, given the steps we have taken so far: An errant "ACL."

So, we'll just get rid of any of these that might exist (was I the guy that said this should be easy????). OK, this time, I want you to be logged into one of your Leopard machines. Mount the old RAID volume remotely, logged into an admin account. Open Terminal. At the prompt, copy and paste this, followed by a <RETURN>:

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

As in the past, when you press <RETURN>, you will be asked for your admin password. Enter it, then again press <RETURN>. While we're at it, I want you to go ahead and run this command again, too; copy and paste the following, followed by a <RETURN>:

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

Going back over your latest post, I notice that you mention this:

The permissions for that particular file are as follows:

everyone No Access

Just to confirm: You are talking about a file you are inspecting that is on the old RAID volume, right? If so, the steps I have outlined in this post should correct whatever problems exist. If it doesn't there is something deeper going on. Really, these steps should be foolproof.

Scott

Keith,

Well, I never said I was perfect. Try this:

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

I think we can just disregard the errors for the removal of ACLs. Apparently, they are not enabled on that volume. Since it is obvious they are not, there is absolutely no reason why the above command will not allow you to copy absolutely everything that exists on that old volume. No reason, unless something is wrong with the files you are trying to copy, themselves. Directory errors can do that.

If you run the command above, and it executes without error, then I want you to go back to the file that read "everyone No Access." Look at that same file. If it still reads "No Access," then the file system is really hosed. If this ends up being the case, there is one more thing that we can try.

We'll get to the bottom of this, eventually. 😉

Scott

Keith,

No, that's nothing to worry about. Let's just get them all copied, and we can any potential problems after everything has been copied.

They are copying, but using what method? The root account, or simply enabling that "Ignore Permissions" option?

In any case, I'll need the name of the new NAS RAID volume, as it appears on the Desktop when mounted. And, let me know to whom you want to assign ownership of the copied files, by short user name ( someone must own the files, and we don't want that ugly "unknown" user to have this ownership).

In the meantime, I want to talk a little about user names in Leopard, and how they affect networking such as you have. Leopard combines some elements of the multi-user environment with the elements of multi-machine networks, thereby bringing a more streamlined "office" environment. In Tiger and earlier versions of OS X, one had to use "Netinfo binding" to get this same streamlined environment. In Leopard, machines will talk to each other as equals, and share user information across the network transparently.

What this means to you is that you can (and maybe should) create identical accounts on all the Leopard machines on your network. Users can then log into any one of the machines using the same credentials as any other, and their access to their own files on the others will be almost automatic. "fred," logged in on machine A, will be recognized by machine B as the same "fred" that exists there, and machine A will automatically supply the proper credentials in order to access those remote files. Whatever access fred has on machine B will be granted to fred sitting at machine A, in other words.

There are still ramifications that must be considered regarding external storage, including that NAS drive, as far as the sequence in which users are created; ramifications that go beyond just the usernames used. User accounts in OS X, including Leopard, are created with User IDs (UIDs) beginning with "501," and proceeding sequentially (502, 503, etc.). In order to make the storage of user files on external storage as seamless as possible, it is prudent to create these account on each machine in the exact same order, so that their UIDs will remain consistent across machines.

If you have already created all of your accounts on all your machines, and your users have settled into those accounts, you need not start over from scratch. If we know what we're doing (and I do), we can change the UIDs as we like. It is relatively easy to make the changes using the GUI in the "Accounts" pane, but doing this would require delving back into Terminal to make that user's files consistent with their new "UID." Even short names can be changed, but then the user's HOME folder would need to be renamed to match. This little change can be made either using the Finder in the root account or by again using Terminal.

My point is not to tell you that "you must do this," but just to let you know that doing it would go a long way toward avoiding future problems with file ownership or access. It is certainly not something that you need to worry about now, but rather when the dust clears from the current troubles you have had.

Scott

Keith,

No, you won't have to go through the process again. That's part of the point. In fact, the idea is that all your humans have accounts on all of your networked machines. They might only sit at one, but they can have some amount of access to every one, said access based on the type of account you create for them on that machine.

There are many advantages to using such a setup. If "fred" is working on a project that would be completed faster if it were being done on a particular machine, he could physically go to that machine for that purpose. Whether the project files are on his "normal" machine or any other would make no difference, because he would always have access to all locations, from all locations.

In such a setup, the act of "passing down" a machine would involve no more than physically moving it. The new user could prepare for this move by copying the contents of the HOME folder they normally use to the HOME folder on the machine they intend to be using, across the network of course. The machine could then be moved, the new user would log into it, and everything would be there for them. Everything.

If you do jump on this, you don't have to do so with both feet, either. If you will be the only person ever using the brand-spanking-new 98 core Mac Pro with 78 TBs of RAM, an array of 6 30" ACDs, and an automatic touch-less car wash that you just leveraged your entire business to buy, and no one will be permitted to approach it any closer than 10 ft., there's no reason you need to create an account on it for anyone else. When you do decide to trade it in for something even better, you need only create an account on it for the recipient, making sure that account has certain specific properties (username, short name, and UID). They would then be able to transfer their files, and they would be ready to accept it and begin using it immediately.

Have a peek for yourself at the things you'll need to control on all your machines: Open System Preferences>Accounts on one of the Leopard machines. Unlock the padlock, then control-click on your own name in the list of users to see the "Advanced Options..." It is here that you will make any changes that you find to be necessary, and it is here that you will gather the information needed to make such a determination (P.S. Don't change anything yet!).

Scott

EDIT: BTW, it's "UID." An "IUD" is something entirely different :-D

G'day Scott,

I have been enjoying the spectator's view from the sidelines (having mistakenly assumed that I was dealing with a SMB share problem at the start of the thread).

Wouldn't the easiest solution for serious file sharing be OS X Server? Then all of the user access is taken care of for you. At $US 500 for 10 clients it's not bad value either.

Cheers,

Rodney

The technical sales person claimed that the LaCie could work as a "server" without needing to dedicate a computer to hosting it.

😉 That is true from the perspective of having a central store of files that everyone can access. It is less true when you have multiple user accounts needing to have different levels of access.

As soon as you get into managing permissions on that central store on a network, you require:

1) A OS X server to manage user accounts and access privileges, OR

2) Some very smart account configuration on the multiple machines in your network (as advised by Scott - if you follow his advice, you don't need OS X server, although user management across multiple machines becomes a manual exercise).

If you don't have one of those, the risk is that files will get "orphaned" in terms of permissions - resulting in a heavy handed work around as you try to get access to the data that is there to be shared.

Lastly, you don't need to dedicate a computer to hosting a server. It is more than possible for OS X server to be run as a normal user machine, even whilst it is still operating as a server (if you have more than a handful of users, this can become problematic though). It also runs on any current Mac hardware without any problems at all.

Cheers,

Rodney

Keith,

Rodney's info is pretty much right on. In your circumstances, OS X Server would bring some ease of functionality that doesn't exist in the client version. For example, OS X Server comes with GUIs for most of the things with which we have been dealing.

Still, I don't think it is necessary for you. Maybe not even appropriate. If you are able to accept and deal with the need to adopt those frameworks and actions that we have thus far discussed ("normalizing" UIDs across your machines, using identical usernames, etc.), your current setup- without an OS X Server in the mix- might even be considered superior.

You see, I like simple. And the setup I have been recommending for you is just that. Granted, it comes with certain strictures within which you must tread, but none of these are difficult to navigate. The objective is to make things as transparent as possible, from the perspective of day to day "operations," with no thinking or troubleshooting required on the part of your users as they go about their business.

When you think you're ready to tackle vetting and changing UIDs/usernames (where necessary) for your users, let me know. We can just take it one step at a time. Based on what information you find as we go, there might not be too much to do.

Scott