3596 Views 14 Replies Latest reply: Apr 22, 2009 3:52 PM by Eden Sarfaty
Check this post by, "joshz" ... http://discussions.apple.com/thread.jspa?threadID=1788541
Anything help there???
That link is available at the top of the Leopard category. http://discussions.apple.com/forum.jspa?forumID=1225
You can set this up with ACLs. It requires a little tinkering on the command line, though.
First go to System Preferences -> Accounts. Unlock the padlock and click the + button. Make a new group (not a new user). Call it something like "sharegroup". Add the users to it to whom you wish to grant access.
Then go to /Users/Shared. Make a new folder there called "sharefolder" or something similar. Move all your files to be shared into this folder.
Then log in to an admin account and paste all three of these lines into Terminal at the same time:
sudo chmod -R +a "sharegroup allow delete,chown,list,search,add_file,\
From this point on, any file or folder you newly create or copy to any location in the sharefolder hierarchy will have full read+write permission to all the users in the group. Note that if the file already exists in a different location and you attempt to move it in, the permissions won't inherit. So hold down the option key when dragging to ensure the file is copied and not moved.
Also, a small number of certain applications (Apple's TextEdit is one of them) will ignore the directive to have new files inherit the permissions and will supply the OS X defaults. You'll have to save these apps' new files in a temporary location first and then copy them in with Finder for the permissions to inherit properly.
Easiest sweetest way is to create a read/write sparse disk image and place it in your /Users/Shared
The default method for mounting disk images will result in the user having full ownership privileges
of all the files & folders contained therein. Thus when scanning a mounted disk image, and copying
data to/from it, there will be no permission related errors. The implications of this become huge
when you realize that anyone who mounts a DMG will have full access. This allows you to share your
data with other users without having to worry about access restrictions. This can be invaluable when
synchronizing with a "central repository" that you need several users to have access to.
Creating a blank disk image for storage
You can use Disk Utility to create a blank disk image to store files. Normally, you need to gather all
the files you want to be included into a single location before you create a disk image. However,
with a blank disk image, you can add files to the image at any time.
To create a blank disk image, Open Disk Utility:
Choose File > New > Blank Disk Image.
Type a name for the disk image, and choose where you want to save it from the pop-up menu.
In Volume name, enter the name for the volume that appears on your desktop when you double
-click the disk image.
Choose the size of the disk image from the Volume Size pop-up menu.
To require a password to open the disk image, choose an encryption scheme from Encryption.
Choose “Single partition - Apple Partition Map” from the Partitions pop-up menu.
Choose “sparse bundle disk image” from the Image Format pop-up menu.
Resizing a disk image
If you can read from and write to a disk image, you can make it larger or smaller when you either
need to save disk space or store more in it.
To resize a disk image:
Open Disk Utility. Select the disk image if it appears in the list of disks and volumes, and then click
Resize in the toolbar.
Otherwise, click Resize in the toolbar, and then select a disk image from the dialog that appears.
Select a new size.
You can even get fancier by creating a small app with automator that will mount the image, then
place it (the app) in each user's login startup item list. Then the image will mount on the desktop
when the user logs in and will be easily accessible like any other mounted disk.
Easiest sweetest way is to create a read/write sparse disk image and place it in your /Users/Shared directory.
You forgot to mention to change the permissions of the .sparseimage file to read+write for the other user. If User A creates a disk image, no other user can modify its contents until User A makes it group or world writable.
But even if that is done, the problem with sparse images is that they do not work well with fast user switching, because sparse disk images cannot be mounted in more than one user account at the same time. If User A mounts the disk image, and then User B logs in, nothing in the disk image will be accessible. User A must log back in, unmount the image, then switch to B, and remount it under that account.
Some might find that an acceptable solution, but it would drive my wife and me nuts!
Very true, if going multi-user (at the same time) disk images won't do.
In that case ACL's are the only good solution. That's how I share my iTunes library.
Another excellent way to share data is to set up and share data on an NTFS drive
(provided of course you are using an NTFS read/write driver).
You can even share your data with your boot camp installation using NTFS.
This works real well using Paragon NTFS. Even the extended attributes are
Carolyn, if I'm reading it right, the post you've linked to warns against "Apply[ing permissions] to enclosed items" at the Home Folder level - which, fortunately, I have not done - and explains how to restore one's Home Folder permissions if one has, unfortunately, done so. There are no permissions issues in moving or copying files between folders in the Home Folder of any of the multiple users on the several Macs on my network. However, I will retain the information on how to restore in case any of my other users applies this command to his or her own Home Folder - so, thanks.
I do use sparse disk images for other purposes, but as Király noted and I have found, they are not useful for this purpose in the context of fast user switching, which is crucial for my workflows.
As for an Automator app, I'm unhappy to say that every time I have attempted to use Automator I have not found a suitable Action or combination thereof to accomplish whatever task it is I'm trying to automate. I suspect that for present purposes an Applescript could be written to use as a Folder Action, but I'm not able to invest the time to learn Applescript. In any event it appears that in lieu of an Automator app I could achieve the same result (to mount a disk image as a Login Item) simply by dragging the disk image or an alias thereof into the Login Items pane of the user in question. Works every time, but has the same deficiency in the context of fast user switching as noted above.
Thank you for your thoughts.
There is also the option of putting the shared documents on a separate hardware volume--either another partition on the boot drive or another drive inside the machine or attached to it externally--with the setting to 'ignore permissions' in its 'Get Info' window.
I tried it, it seems to work: every user can access files, edit and save them, or delete them. Users connecting from another machine on the local network can also do so. Time Machine/Capsule automatically backs up the contents of the drive, at least when it is internal (my situation).
If I adopt it, backups will be more complicated, it might also affect performance.
I think I would rather partition one drive into two partitions: a boot partition for system, applications and user folders, and a shared partition for shared documents. Is that better/worse than having two separate drives running in the same machine?
Anyone have experience of this, or pros and cons to consider?
In fact, I had previously created a "sharegroup" for this purpose : )
However, the folder I have specifically designated for this function is a sub-folder of my own (User1) Shared Folder. I don't see that this should make any difference - should it? - apart from the fact that the Terminal commands you have provided would have to be slightly modified, which I am not competent to do without validation from someone who is. For example:
sudo chmod -R +a "sharegroup allow delete,chown,list,search,add_file,\
Apart from whether I've got what I think should be a couple of simple substitutions right, I do not understand why the same inheritance properties are not carried by the "Apply to enclosed items" command under the Action button in the Sharing and Permissions pane of the Get Info window. It seems to me that if all one wanted to do was to change the permissions for the items that are in the folder at a specific time, without automatically applying those permissions to any future items created or copied to that folder, all one would have to do would be to Edit>Select All, File>Show Inspector, then unlock and change the permissions.
Such are the persistent infelicities of OS X. Maybe Snow Leopard. Nah.
Message was edited by: Eden Sarfaty
I presently do what you are suggesting for some sharing purposes (for example, an iPhoto Library) on an external network drive that has several sharepoints, each of which has a different set of user permissions, ranging from different single users to all users. But it does indeed complicate backup, it can affect performance when what one is doing is processor- or network-heavy, and it is rather cumbersome for what should be a simple built-in function of the multi-user sharing scheme.
In 10.3 and earlier I used to do exactly that - put my shared stuff on an external drive and check the Ignore Ownership button. All files were available to all users then with full read+write permission.
But that made backups tedious. When 10.4 came along I was happy to dump the old method and move all my files to the boot volume, and set the ACLs to accomplish the same thing. Been doing that ever since.
Eden Sarfaty, the Terminal command you included in an above post looks just fine to me.
"In fact, I had previously created a "sharegroup" for this purpose : )
However, the folder I have specifically designated for this function is a sub-folder of my own (User1) Shared Folder. I don't see that this should make any difference - should it?"
If a folder is in your home directory it will not be accessible by other users unless it on the first level
(where your Public and Sites folder is located).
"I do not understand why the same inheritance properties are not carried by the "Apply to enclosed items" command under the Action button in the Sharing and Permissions pane of the Get Info window."
Finder's permission handling is crude and unpredictable. All I ever use it for is getting a quick look
Do yourself a favor and get yourself a good posix permissions program like FileXaminer and learn
the terminal commands chmod and chown. The terminal is still the King when it comes to changing
permissions on directory structures and apps.
For ACL management, Sandbox is the only GUI available. Chmod is still the most powerful ACL
manager though, as it can place and remove ACL's on files as well as folders and can traverse
directory structures easily.
"If a folder is in your home directory it will not be accessible by other users unless it on the first level
(where your Public and Sites folder is located)."
Well, I can't say I've seen this helpful little fact before. Thank you. And for the light-reading links you provided, thank you as well. For all the time I've spent rooting around now and again, I'm sure I could have read them. Maybe even understood them : )