Hunterloft662

• If the computers are on the same local network, why not share the files directly via network itself. We have previously seen how to transfer files between Ubuntu and Windows on local network. Today we are going to see an even easier way to transfer files among Linux, Windows and Mac OS X on local network. For this purpose, we’ll be using an.
• To upload files to OneDrive automatically, just copy or move the files to your OneDrive folder using the Finder, or save them in your OneDrive folder from an app. Files you upload this way can be up to 100GB in size if you're signed in to a Microsoft account, or 15GB if you're signed in to a work or school account.

• How To Share File Between Users On Mac
• Share Files Between Users Windows 10

Click here to return to the '10.5: Share any files between users on the same Mac' hint

10.5: Share any files between users on the same Mac Jun 04, '09 07:30:02AM. Contributed by: Anonymous 10.5: For a long time now, I've wished that there was a way in OS X to create a shared folder which disregarded file permissions.

I wonder: Is there still no easy-to-use tool with a graphic user interface for checking and modifying ACLs on OS X?
If so, maybe it's time for someone to write one...

Finally! man I've been waiting for this hint for a long time. The inability to share iphoto and itunes is maddening.
However, I assume locking is there for a reason. That is it's quite easy to accidentally get two copies of iphoto running when you have two user accounts. It happens when you have a camera plugged in and then fast user switch. iphoto can autostart in both user accounts. You could imagine that if both are writing to the same database it could get ugly.
what I've noticed is that if I have itunes pointed to the same directory from both users that right now that when the second itunes app launches it refuses to run because it detects the other itunes app has locked something. so that's a safety I guess.
But I don't know how it does this. if it uses permissions to regulate access then maybe that will screw up the handshake?
what's your experience on that? Can two copies of itunes or iphoto run after you do this?

Couldn't this have been done easier by creating the group and then giving the group read/write permissions to the directory?

sudo chmod g+rwx Friday

oops:
chgrp friday Friday
chmod g+rwxs Friday
The 's' means that files created in/copied to that directory will inherit the group of the directory.

This would work for the existing files in the directory, but probably wouldn't work for any new files. In my experience with POSIX permissions, when you copy a file into a directory, it will generally inherit the directory's owner, but it will not inherit the permission bits assigned to the directory.
For created files, the directory's set-UID and set-GID permission bits must be set in order for the file to be assigned the directory's user and group (or else it will be assigned to whatever user created the file). The permissions for the file will most likely be 755 (but that may be different if you altered the umask).
The tip listed above attempts to overcome these issues by using an ACL on the shared directory which is generally better at getting new files within that directory to conform to the directory's permissions.

I haven't tested this, but I think you can just:

1. open the Sharing Preferences
2. enable File Sharing
3. add the folder you want to share, and
4. choose what users get to share it.

you probably have more fine-grained control using ACLs, of course, but this seems a lot simpler.

That won't accomplish what this hint does. With this hint, any files created in the Friday folder can be read, written, and executed by everyone. So if your user adds a photo to iPhoto, your wife's user can edit it.
With just sharing, you are getting nothing more than the permissions on the Shared folder already allow: anyone can read, write, and browse the folder itself, but the files and subfolders in the folder remain subject to the usual permissions restrictions. So if your user added a photo to iPhoto, your wife's user could not edit it.

err... I'm trying to imagine a case where you'd want to give other users permission to execute arbitrary code in your user space. at best, it adds no value that can't be accomplished by putting scripts in /Library for general access; at worst it's a huge security hole.

execution aside, file sharing can set read and write privileges - so yes, in fact, your wife could open, edit, and save your iPhoto entires from her account (assuming you're married; if you're not, and she does, that would be confusing). you may need to move your iPhoto folders into the shared folder, or easier, you could use the sharing panel to make your iPhoto folder shared in and of itself (which I think automatically propagates to its subfolders). what advantage does the command-line approach offer over the file sharing panel, aside from that highly questionable execution issue?

Execution matters because opening a folder is in fact 'executing' it. Intuitively one might think that opening a folder involved 'reading' it, but in this case intuition in incorrect.
Have you ever tried to look inside another user's home folder and found folders with little 'no access' icons on them that you couldn't open? This is because your user does not have execute permissions for that folder. This is the mechanism used to create the drop box folder inside your user's public folder: everyone has write permissions for the drop box (i.e. they can add files to it), but only you have execute permissions (i.e. only you can see what is inside it).
This matters a lot for things like iPhoto and iTunes libraries, because if a newly created folder inside one of those libraries is not executable by everyone, then the most recently added photos (to return to my previous example), which are stored in their own subfolder, will not be available to any user other than the one who first added them.

in fact, no.

I just tested this on my system: I enabled file sharing, added the pictures folder from a different account to the shared folders column, gave everyone read and write permission, enabled my main account and the other account in the 'options' section, and then voila! I went and opened a picture from the pictures folder on the other account, and saved it back to the other account under a different file name. the little 'no access' badge that's normally on the another user account's pictures folder disappears as soon as I enable sharing for that folder (though it still appears in the system preferences panel until you quit and restart that app).

have you tried it? in this case my 'intuition' seems to be backed up by practical evidence. I understand what you're saying, and it makes a certain degree of sense within the twisted universe of pure unix, but don't underestimate Apple's ability to make functional GUI methods.

I did try it, apparently more thoroughly than you did.
Sharing a folder with read and write permissions will allow another user or group to open the folder and to put files into the folder (yes, Apple's GUI is simplifying read, write & execute into simply 'read & write'). But sharing the folder doesn't allow another user to edit a file inside the folder unless and until the permissions on the individual file in question are manually modified (via Finder's Info window or the command line or some other method).
So if my wife's user adds some documents to a shared folder, I can see the document files in the folder and even open them up to read them, but I can't save any changes to them. If I try, I get an error about not having the proper access privileges.
Having to manually modify the permissions on a file isn't too bad to work with for an occasional individual file, but when dealing with the innards of an iPhoto or iTunes library, where many files all over the place are being added and edited all the time, one needs a system in place that will take care of all the permissions issues on all the files and subfolders automatically. That's what this hint about ACLs provides.

Addendum:
The key point here is that in your test you 'saved it back to the other account under a different file name.' You had to save it into the shared folder with a new name because you were only allowed to create new files, not to edit ones you didn't already own. That won't work when dealing with iTunes and iPhoto. They need to be able to edit files, or the library breaks.

Also, this hint doesn't give other users 'permission to execute arbitrary code in your user space.' Any code they might execute is run as themselves, not as you.

Perhaps you have this confused with the setuid and setgid bits, which do allow a user to run code as if they were someone else.

This hint describes using the ACLs to set permissions on a folder inside /Users/Shared, not a user's home folder (/Users/username). A bash script such as the one you mention would only affect the Shared folder, not anyone's home folder.

'err... I'm trying to imagine a case where you'd want to give other users permission to execute arbitrary code in your user space.'
How about your spouse who also uses your home Mac? My wife wouldn't want to and wouldn't know how to 'execute arbitrary code' (which I assume is a bizarre phrase meaning 'run malware').
I gave up on separate 'his' and 'her' accounts years ago, because the benefits were too small to justify the hassles. Our main account is a regular user account. I maintain the admin account. iTunes and some iPhoto files are shared across accounts.

I can see you've never been through a nasty break-up. :) and (knock wood) you never will. my philosophy is 'don't fix what aint broke' but also 'don't make something that breaks just cuz you can't imagine having to fix it'.

Now you are just being silly. If you had a nasty breakup, why are you giving this girl access to your machine? Delete her account, and then she won't be able to log in at all.

dude, you rarely know in advance that you're going to have a nasty breakup.
I don't actually know whether you're right or wrong about the other stuff, but you're way too involved in the issue for me to bother discussing it further. do it the way you want to do it; not a big issue either way.

I did the trick using PrefPane and it works...
I compared the result for the 'ls -le' and it's exactly the same. (oops sorry for the mistake: the group's name and the folder's name are not the same)

I also posted this in reply to tedw, but its buried in there and I thought you might not see it, ragmaxone. I'd hate for you to accidentally mess up your iPhoto or iTunes library, so I'm reposting it here too. :)
Sharing a folder with read and write permissions will allow another user or group to open the folder and to put files into the folder (yes, Apple's GUI is simplifying read, write & execute into simply 'read & write'). But sharing the folder doesn't allow another user to edit a file inside the folder unless and until the permissions on the individual file in question are manually modified (via Finder's Info window or the command line or some other method).
So if my wife's user adds some documents to a shared folder, I can see the document files in the folder and even open them up to read them, but I can't save any changes to them. If I try, I get an error about not having the proper access privileges.
Having to manually modify the permissions on a file isn't too bad to work with for an occasional individual file, but when dealing with the innards of an iPhoto or iTunes library, where many files all over the place are being added and edited all the time, one needs a system in place that will take care of all the permissions issues on all the files and subfolders automatically. That's what this hint about ACLs provides.

I tried this on Leopard 10.5.7 bound to AD (but not OD, no magic triangle) for the AD-group 'Domain Users', but both command line and Sandbox application fail with error message:

chmod: Unable to translate 'INTRANETdomain' to a UID/GID

Looks like the space is the problem, and neither quoting or escaping did help (group:'INTRANETdomain users' ... 'group:INTRANETdomain users'). Since Sandbox neither handles this correctly, I am wondering if this is a parsing bug in chmod?

I am not getting it. There already is a Shared folder in the Users folder. This folder is read/write for all users. If you keep your iTunes music and your iPhoto files there, they can be accessed by all users. Any other documents in the Shared folder are accessible to all users.
If you need to share almost everything, then why have separate user files at all?

The files in our Shared folders all are editable by the original owner but the group [wheel] and others have read only.
Periodically we push the Shared folder's permissions (group and others have read-write) down to all documents in the Shared folder, but this ACL thing would make our lives somewhat easier.

As I mentioned in reply to another comment above, everyone has full permissions for the Shared folder itself, but any files inside the Shared folder are another matter.

Under normal conditions, both User1 and User2 can add files to the Shared folder, and typically User2 can read User1's files that are stored there, but normally User2 cannot edit User1's files. Even though the folder is freely open to everyone, the file remains under the usual restrictions.

What this hint does is set things up so that files added to the Shared folder (or rather, if you follow the hint's directions precisely, a folder within the Shared folder) automatically have their permissions modified so that anyone can do anything with the files themselves.

'Under normal conditions, both User1 and User2 can add files to the Shared folder, and typically User2 can read User1's files that are stored there, but normally User2 cannot edit User1's files.'
I haven't seen this unless a user deliberately protects a file. I've been able to edit from the User2 account iTunes, iPhoto, Excel, Word, AppleScript, Canvas, GraphicConverter, Preview and other files created in the User1 account and placed in the Shared users folder. My Shared folder has permissions set at read & write for me, system, wheel, and everyone.

Step 3 in Terminal doesn't work (on my Mac anyway), as you change the owner to admin, which is actually a group and my Mac doesn't allow two groups as owner and group.

This is probably a cool and useful hint for a single-drive, single-volume Mac, but I've rarely owned one of those where EVERYONE had to use the same files, the exception being the iTunes Library, and even then I *always* use partitioning to create at least a Users volume, and usually a Media volume, as well.
On any tower I always have a Users drive and a Media (or simply 'Shared Files') drive, too; both of these strategies have saved my butt dozens of times when the System volume becomes un-bootable *and* unmountable for various reasons. It's also super-helpful for backup strategies of data that doesn't change often enough to warrant daily/weekly or even monthly backups.
The point of this is that the Media/Shared Files drive/volume is simply set to 'Ignore Ownership on This Volume', and the /Users/Shared/ folder's various Music/Movies/Icons/Pictures/Wallpapers/Installers/etc. is/are Symlinked to live on the Media volume, thus having zero permissions issues.
Accomplishes everything in your hint, with little fuss, and, unlike the other commenters suggesting Shared folders as alternative, your local all-access volumes can be hidden from network sharing altogether, should security of the shared folder be desired to be restricted to local access only.
Still, ACLs are totally cool, and I appreciate this hint for it's potential other uses.
Cheers
Rico

For those who don't have an already partitioned drive, could a similar thing be accomplished by keeping the iTunes library on a sparse disk image, again with 'ignore ownership on this volume' checked?

A quick test with a handful of songs says yes. Very cool idea, BTW. Could be very, very useful; e.g., to share adult content (explicit songs, NC-17 movies, etc.) from the same computer by simply password-protecting the disk image.
Possible drawbacks would include slower access time and possible frame-rate drops for HD content unless the DMG is located on a very fast drive or a raid.
This might qualify as a hint unto itself, don't you think, Rob G.?

Brand spanking new Mac User here. I followed your directions, but on Step 3 my new MacBook Pro (as in maybe a week old) returned 'invalid argument'. I searched the comments, tried again, then settled on trying a posters suggestion:
chgrp friday Friday
Seems to have worked. But now, my iPod Touch won't sync.
I tried just about everything short of restarting the iPod (holding down the Home and Lock buttons). My iPod's there, with the battery level and eject button. No sync option anywhere (unless there is a hidden one).
I can only think it's a consequence of something I did. Could be unrelated I suppose, but I didn't mess with it beforehand. At this point, I am willing to to try it all, even if you think I skipped a step, pipe up. If I delete the group and folder I created, can I start from the top?

Finder was displaying a no-entry traffic sign icon on the shared folder ('/Users/Shared/Friday' in the article), and I could not double-click it to open it.

The solution is to add execute to the ACL, like this:

Can someone help me? I typed in the command while in Terminal, 'sudo chown admin:friday Friday' and it asks me for a password. I chose not to set-up a system password on my iMac so when I install program updates and it asks for a password I just hit enter and it installs the updates. If I just press enter within Terminal it does nothing and after 3 attempts it kicks me out of the command. Is there a different command I need to use when you don't have a password?

Very risky thing to do. But anyway each to their own. I suggest you temporarily assign a password to the account your using. Use the Users and Groups System Preferences panel. Later you can remove you password by going through the same process and instead leave new password fields blank. Expect a warning from the OS about doing this.

This line: sudo chown admin:friday Friday
returned the error message: 'chown: admin: Invalid argument'
So I substituted the following: chown :friday Friday
which seemed to work.

Ok I did some research. I looked into the syntax to try to understand what I was telling the terminal to do and it revealed the issue. Hope this helps someone else.
The line as printed above at the time of this writing is as follows:
sudo chown admin:friday Friday
it is telling terminal to change the owner to admin and the group to friday and apply to the file/folder Friday. the error is returned in my case because admin doesn't exist. I was confused by this because there is a group called admin, not the same thing. So the resulting error was a syntax error.
So I suggest trying to substitute the owner 'admin in this case' with one of your admin accounts e.g. Fred.
sudo chown Fred:friday Friday
Hope that was correct and makes sense.

I'm also getting 'Invalid argument'. I've tried all the variations mentioned above with either the same response or 'command not found'... Trying to do this on 10.7.1
I've checked my spellings etc. All appears to be correct as far as I can tell from what's written here.
Please help, I really want to resolve this.

Click here to return to the '10.5: Share any files between users on the same Mac' hint

I wonder: Is there still no easy-to-use tool with a graphic user interface for checking and modifying ACLs on OS X?
If so, maybe it's time for someone to write one...

How To Share File Between Users On Mac

Finally! man I've been waiting for this hint for a long time. The inability to share iphoto and itunes is maddening.
However, I assume locking is there for a reason. That is it's quite easy to accidentally get two copies of iphoto running when you have two user accounts. It happens when you have a camera plugged in and then fast user switch. iphoto can autostart in both user accounts. You could imagine that if both are writing to the same database it could get ugly.
what I've noticed is that if I have itunes pointed to the same directory from both users that right now that when the second itunes app launches it refuses to run because it detects the other itunes app has locked something. so that's a safety I guess.
But I don't know how it does this. if it uses permissions to regulate access then maybe that will screw up the handshake?
what's your experience on that? Can two copies of itunes or iphoto run after you do this?

Couldn't this have been done easier by creating the group and then giving the group read/write permissions to the directory?

sudo chmod g+rwx Friday

oops:
chgrp friday Friday
chmod g+rwxs Friday
The 's' means that files created in/copied to that directory will inherit the group of the directory.

This would work for the existing files in the directory, but probably wouldn't work for any new files. In my experience with POSIX permissions, when you copy a file into a directory, it will generally inherit the directory's owner, but it will not inherit the permission bits assigned to the directory.
For created files, the directory's set-UID and set-GID permission bits must be set in order for the file to be assigned the directory's user and group (or else it will be assigned to whatever user created the file). The permissions for the file will most likely be 755 (but that may be different if you altered the umask).
The tip listed above attempts to overcome these issues by using an ACL on the shared directory which is generally better at getting new files within that directory to conform to the directory's permissions.

I haven't tested this, but I think you can just:

1. open the Sharing Preferences
2. enable File Sharing
3. add the folder you want to share, and
4. choose what users get to share it.

you probably have more fine-grained control using ACLs, of course, but this seems a lot simpler.

That won't accomplish what this hint does. With this hint, any files created in the Friday folder can be read, written, and executed by everyone. So if your user adds a photo to iPhoto, your wife's user can edit it.
With just sharing, you are getting nothing more than the permissions on the Shared folder already allow: anyone can read, write, and browse the folder itself, but the files and subfolders in the folder remain subject to the usual permissions restrictions. So if your user added a photo to iPhoto, your wife's user could not edit it.

err... I'm trying to imagine a case where you'd want to give other users permission to execute arbitrary code in your user space. at best, it adds no value that can't be accomplished by putting scripts in /Library for general access; at worst it's a huge security hole.

execution aside, file sharing can set read and write privileges - so yes, in fact, your wife could open, edit, and save your iPhoto entires from her account (assuming you're married; if you're not, and she does, that would be confusing). you may need to move your iPhoto folders into the shared folder, or easier, you could use the sharing panel to make your iPhoto folder shared in and of itself (which I think automatically propagates to its subfolders). what advantage does the command-line approach offer over the file sharing panel, aside from that highly questionable execution issue?

Execution matters because opening a folder is in fact 'executing' it. Intuitively one might think that opening a folder involved 'reading' it, but in this case intuition in incorrect.
Have you ever tried to look inside another user's home folder and found folders with little 'no access' icons on them that you couldn't open? This is because your user does not have execute permissions for that folder. This is the mechanism used to create the drop box folder inside your user's public folder: everyone has write permissions for the drop box (i.e. they can add files to it), but only you have execute permissions (i.e. only you can see what is inside it).
This matters a lot for things like iPhoto and iTunes libraries, because if a newly created folder inside one of those libraries is not executable by everyone, then the most recently added photos (to return to my previous example), which are stored in their own subfolder, will not be available to any user other than the one who first added them.

Share Files Between Users Windows 10

in fact, no.

I just tested this on my system: I enabled file sharing, added the pictures folder from a different account to the shared folders column, gave everyone read and write permission, enabled my main account and the other account in the 'options' section, and then voila! I went and opened a picture from the pictures folder on the other account, and saved it back to the other account under a different file name. the little 'no access' badge that's normally on the another user account's pictures folder disappears as soon as I enable sharing for that folder (though it still appears in the system preferences panel until you quit and restart that app).

have you tried it? in this case my 'intuition' seems to be backed up by practical evidence. I understand what you're saying, and it makes a certain degree of sense within the twisted universe of pure unix, but don't underestimate Apple's ability to make functional GUI methods.

I did try it, apparently more thoroughly than you did.
Sharing a folder with read and write permissions will allow another user or group to open the folder and to put files into the folder (yes, Apple's GUI is simplifying read, write & execute into simply 'read & write'). But sharing the folder doesn't allow another user to edit a file inside the folder unless and until the permissions on the individual file in question are manually modified (via Finder's Info window or the command line or some other method).
So if my wife's user adds some documents to a shared folder, I can see the document files in the folder and even open them up to read them, but I can't save any changes to them. If I try, I get an error about not having the proper access privileges.
Having to manually modify the permissions on a file isn't too bad to work with for an occasional individual file, but when dealing with the innards of an iPhoto or iTunes library, where many files all over the place are being added and edited all the time, one needs a system in place that will take care of all the permissions issues on all the files and subfolders automatically. That's what this hint about ACLs provides.

Addendum:
The key point here is that in your test you 'saved it back to the other account under a different file name.' You had to save it into the shared folder with a new name because you were only allowed to create new files, not to edit ones you didn't already own. That won't work when dealing with iTunes and iPhoto. They need to be able to edit files, or the library breaks.

Also, this hint doesn't give other users 'permission to execute arbitrary code in your user space.' Any code they might execute is run as themselves, not as you.

Perhaps you have this confused with the setuid and setgid bits, which do allow a user to run code as if they were someone else.

This hint describes using the ACLs to set permissions on a folder inside /Users/Shared, not a user's home folder (/Users/username). A bash script such as the one you mention would only affect the Shared folder, not anyone's home folder.

'err... I'm trying to imagine a case where you'd want to give other users permission to execute arbitrary code in your user space.'
How about your spouse who also uses your home Mac? My wife wouldn't want to and wouldn't know how to 'execute arbitrary code' (which I assume is a bizarre phrase meaning 'run malware').
I gave up on separate 'his' and 'her' accounts years ago, because the benefits were too small to justify the hassles. Our main account is a regular user account. I maintain the admin account. iTunes and some iPhoto files are shared across accounts.

I can see you've never been through a nasty break-up. :) and (knock wood) you never will. my philosophy is 'don't fix what aint broke' but also 'don't make something that breaks just cuz you can't imagine having to fix it'.

Now you are just being silly. If you had a nasty breakup, why are you giving this girl access to your machine? Delete her account, and then she won't be able to log in at all.

dude, you rarely know in advance that you're going to have a nasty breakup.
I don't actually know whether you're right or wrong about the other stuff, but you're way too involved in the issue for me to bother discussing it further. do it the way you want to do it; not a big issue either way.

I did the trick using PrefPane and it works...
I compared the result for the 'ls -le' and it's exactly the same. (oops sorry for the mistake: the group's name and the folder's name are not the same)

I also posted this in reply to tedw, but its buried in there and I thought you might not see it, ragmaxone. I'd hate for you to accidentally mess up your iPhoto or iTunes library, so I'm reposting it here too. :)
Sharing a folder with read and write permissions will allow another user or group to open the folder and to put files into the folder (yes, Apple's GUI is simplifying read, write & execute into simply 'read & write'). But sharing the folder doesn't allow another user to edit a file inside the folder unless and until the permissions on the individual file in question are manually modified (via Finder's Info window or the command line or some other method).
So if my wife's user adds some documents to a shared folder, I can see the document files in the folder and even open them up to read them, but I can't save any changes to them. If I try, I get an error about not having the proper access privileges.
Having to manually modify the permissions on a file isn't too bad to work with for an occasional individual file, but when dealing with the innards of an iPhoto or iTunes library, where many files all over the place are being added and edited all the time, one needs a system in place that will take care of all the permissions issues on all the files and subfolders automatically. That's what this hint about ACLs provides.

I tried this on Leopard 10.5.7 bound to AD (but not OD, no magic triangle) for the AD-group 'Domain Users', but both command line and Sandbox application fail with error message:

chmod: Unable to translate 'INTRANETdomain' to a UID/GID

Looks like the space is the problem, and neither quoting or escaping did help (group:'INTRANETdomain users' ... 'group:INTRANETdomain users'). Since Sandbox neither handles this correctly, I am wondering if this is a parsing bug in chmod?

I am not getting it. There already is a Shared folder in the Users folder. This folder is read/write for all users. If you keep your iTunes music and your iPhoto files there, they can be accessed by all users. Any other documents in the Shared folder are accessible to all users.
If you need to share almost everything, then why have separate user files at all?

The files in our Shared folders all are editable by the original owner but the group [wheel] and others have read only.
Periodically we push the Shared folder's permissions (group and others have read-write) down to all documents in the Shared folder, but this ACL thing would make our lives somewhat easier.

As I mentioned in reply to another comment above, everyone has full permissions for the Shared folder itself, but any files inside the Shared folder are another matter.

Under normal conditions, both User1 and User2 can add files to the Shared folder, and typically User2 can read User1's files that are stored there, but normally User2 cannot edit User1's files. Even though the folder is freely open to everyone, the file remains under the usual restrictions.

What this hint does is set things up so that files added to the Shared folder (or rather, if you follow the hint's directions precisely, a folder within the Shared folder) automatically have their permissions modified so that anyone can do anything with the files themselves.

'Under normal conditions, both User1 and User2 can add files to the Shared folder, and typically User2 can read User1's files that are stored there, but normally User2 cannot edit User1's files.'
I haven't seen this unless a user deliberately protects a file. I've been able to edit from the User2 account iTunes, iPhoto, Excel, Word, AppleScript, Canvas, GraphicConverter, Preview and other files created in the User1 account and placed in the Shared users folder. My Shared folder has permissions set at read & write for me, system, wheel, and everyone.

Step 3 in Terminal doesn't work (on my Mac anyway), as you change the owner to admin, which is actually a group and my Mac doesn't allow two groups as owner and group.

This is probably a cool and useful hint for a single-drive, single-volume Mac, but I've rarely owned one of those where EVERYONE had to use the same files, the exception being the iTunes Library, and even then I *always* use partitioning to create at least a Users volume, and usually a Media volume, as well.
On any tower I always have a Users drive and a Media (or simply 'Shared Files') drive, too; both of these strategies have saved my butt dozens of times when the System volume becomes un-bootable *and* unmountable for various reasons. It's also super-helpful for backup strategies of data that doesn't change often enough to warrant daily/weekly or even monthly backups.
The point of this is that the Media/Shared Files drive/volume is simply set to 'Ignore Ownership on This Volume', and the /Users/Shared/ folder's various Music/Movies/Icons/Pictures/Wallpapers/Installers/etc. is/are Symlinked to live on the Media volume, thus having zero permissions issues.
Accomplishes everything in your hint, with little fuss, and, unlike the other commenters suggesting Shared folders as alternative, your local all-access volumes can be hidden from network sharing altogether, should security of the shared folder be desired to be restricted to local access only.
Still, ACLs are totally cool, and I appreciate this hint for it's potential other uses.
Cheers
Rico

For those who don't have an already partitioned drive, could a similar thing be accomplished by keeping the iTunes library on a sparse disk image, again with 'ignore ownership on this volume' checked?

A quick test with a handful of songs says yes. Very cool idea, BTW. Could be very, very useful; e.g., to share adult content (explicit songs, NC-17 movies, etc.) from the same computer by simply password-protecting the disk image.
Possible drawbacks would include slower access time and possible frame-rate drops for HD content unless the DMG is located on a very fast drive or a raid.
This might qualify as a hint unto itself, don't you think, Rob G.?

Brand spanking new Mac User here. I followed your directions, but on Step 3 my new MacBook Pro (as in maybe a week old) returned 'invalid argument'. I searched the comments, tried again, then settled on trying a posters suggestion:
chgrp friday Friday
Seems to have worked. But now, my iPod Touch won't sync.
I tried just about everything short of restarting the iPod (holding down the Home and Lock buttons). My iPod's there, with the battery level and eject button. No sync option anywhere (unless there is a hidden one).
I can only think it's a consequence of something I did. Could be unrelated I suppose, but I didn't mess with it beforehand. At this point, I am willing to to try it all, even if you think I skipped a step, pipe up. If I delete the group and folder I created, can I start from the top?

Finder was displaying a no-entry traffic sign icon on the shared folder ('/Users/Shared/Friday' in the article), and I could not double-click it to open it.

The solution is to add execute to the ACL, like this:

Can someone help me? I typed in the command while in Terminal, 'sudo chown admin:friday Friday' and it asks me for a password. I chose not to set-up a system password on my iMac so when I install program updates and it asks for a password I just hit enter and it installs the updates. If I just press enter within Terminal it does nothing and after 3 attempts it kicks me out of the command. Is there a different command I need to use when you don't have a password?

Very risky thing to do. But anyway each to their own. I suggest you temporarily assign a password to the account your using. Use the Users and Groups System Preferences panel. Later you can remove you password by going through the same process and instead leave new password fields blank. Expect a warning from the OS about doing this.

This line: sudo chown admin:friday Friday
returned the error message: 'chown: admin: Invalid argument'
So I substituted the following: chown :friday Friday
which seemed to work.

Ok I did some research. I looked into the syntax to try to understand what I was telling the terminal to do and it revealed the issue. Hope this helps someone else.
The line as printed above at the time of this writing is as follows:
sudo chown admin:friday Friday
it is telling terminal to change the owner to admin and the group to friday and apply to the file/folder Friday. the error is returned in my case because admin doesn't exist. I was confused by this because there is a group called admin, not the same thing. So the resulting error was a syntax error.
So I suggest trying to substitute the owner 'admin in this case' with one of your admin accounts e.g. Fred.
sudo chown Fred:friday Friday
Hope that was correct and makes sense.

I'm also getting 'Invalid argument'. I've tried all the variations mentioned above with either the same response or 'command not found'... Trying to do this on 10.7.1
I've checked my spellings etc. All appears to be correct as far as I can tell from what's written here.
Please help, I really want to resolve this.