NOTE: THIS UTILITY SHOULD NO LONGER BE NEEDED DUE TO APPLE UPDATING BOOT CAMP ASSISTANT TO USE EXFAT. WE HAVE LEFT THIS ARTICLE AND THE DOWNLOAD FOR HISTORICAL PURPOSES. IT IS NO LONGER SUPPORTED.

The AutoRecovery folder is a hidden folder, so you probably won't see it if you just try to navigate to it in Finder. Use the Go To Folder tool and enter the full path to get around this. If you close a file and click Don't Save, the AutoRecover file will be deleted because Office assumes that everything is ok and the AutoRecover file isn't needed. Enjoy worry-free unhackable online life with real-time malware threat elimination within unbreakable Web defense.

In the last few months, people installing Windows on their Macs with Boot Camp Assistant havestartedseeingthe message “An Error occurred while copying the Windows installation files” when using some Windows 10 ISO downloaded from Microsoft. I have seen it a lot, since I do testing with ISO of Windows Enterprise downloaded from Microsoft that have been showing this problem. It didn’t seem to happen with all ISO so I investigated the issue, filed a bug with Apple, and figured out a workaround to the problem.

The Cause

When Windows 10 is installed with Boot Camp Assistant, Boot Camp Assistant prepares the disk for installation. To do this, it does the following operations:

1. Download the Windows Support software from Apple for the current Mac.
2. Creates 2 partitions, one where Windows will be installed (“BOOTCAMP”) and one where the installer files will reside (“OSXRESERVED”). Both are formatted as FAT32.
3. Copies all the files from the ISO that was specified at the start of the process by the user to the OSXRESERVED partition. This is where the error happens.
4. Copies the files from the WindowsSupport to the OSXRESERVED partition. These files provide both the drivers needed when installing and the drivers that are installed post-install.
5. Sets the boot disk to the OSXRESERVED partition and reboots.

Windows boots from the OSXRESERVED and shows the available editions of Windows from the install.wim file in the support folder on OSXRESERVED. This is a large file (usually around 4 GB). The install.wim contains all of the files for a vanilla copy of Windows 10 and is the largest file in the installer ISO.

So, here is where the problem resides: FAT32 cannot handle files greater than 4 GB. Each new version of Windows increases the size of this file, and ISOs that contain more editions of Windows can be larger than other ISOs that contain less editions.

In step 3 above, the error message “An Error occurred while copying the Windows installation files” is shown because Boot Camp assistant cannot copy the install.wim to a FAT32 filesystem. This file is required, so the whole process aborts.

To make matters even worse, the disk in the Mac is left in a state where it is difficult to revert back to a single partition. The OSXRESERVED partition is hidden and unmounted, and Boot Camp Assistant cannot restore a disk that has multiple FAT32 partitions.

The Solution

To resolve this issue, both FAT32 partitions need to be removed from the disk and a new ISO must be created where no single file is larger than 4GB. We have created a free utility called “Boot Camp ISO Converter” that copies all the files in the ISO to a folder, splits up the install.wim into parts no larger than 2GB, and creates a new ISO that can be used with Boot Camp Assistant. Here is a step-by-step instructions:

Removing the installer partitions

1. Make sure you have a good backup of all files on the disk that could be lost, including all the Mac files. Repartitioning could fail due to drive errors, so having a good backup is important.
2. Open Disk Utility, select the startup disk, and click the partition button.
3. Select the OSXRESERVED partition and click the “-” button to remove the partition.
4. Select the BOOTCAMP partition and click the “-” button to remove the partition.
5. Click Apply to start the partition removal process.

Splitting the ISO

1. Download Boot Camp ISO Converter (https://twocanoes-software-updates.s3.amazonaws.com/Boot%20Camp%20ISO%20Converter1_6.dmg) and install.
2. Open Boot Camp ISO Converter and select the ISO that caused the error.
3. Click “Save…” and specify a name and location for the new ISO.
4. After the operation is completed, the new ISO can be used to install Windows with Boot Camp assistant following the standard process.

Boot Camp ISO Converter

Boot Camp ISO Converter uses a command like tool called “wimsplit” to split the wim into parts no larger than 2GB. The WIM format supports split files; when installing Windows, the Windows installer recognizes the split files as treats them as a single large file, as long as all the split files are in the same folder. If you look in the sources folder on the new ISO, you will see multiple install.swm files with a number appended on the end.

If you like this article and want to hear more, sign up for our newsletter or follow us on Twitter.

On your Mac, choose Apple menu System Preferences, then click Sharing. Select the File Sharing checkbox. To select a specific folder to share, click the Add button at the bottom of the Shared Folders list, locate the folder, select it, then click Add. The Public folder of each user with an account on your Mac is shared automatically. The basic way to share files between Macs is to use File Sharing. To use this feature. To access the Shared folder, simply open the Finder and select the Go menu, then select Go to folder. (or type command-shift-G). Then type /Users and hit return. You should be staring at the list of user folders on your Mac, with a Shared folder there as well.

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...

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.

How To Share Files On Macbook Between Users

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...

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,

Mac Share Files Over Network

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.

How To Share A File

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?

Connect To Windows Share From Mac

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?

Mac English Directory Program For Window Oscar

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.

How To Share Files With Users On Mac

Mac English Directory Program For Window Os 7

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.

How To Share Files On Network

Mac English Directory Program For Window Osx

How To Share Files For Different Users On Mac Os Catalina

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.