Open the Sharing panel in the System Preferences and select the File Sharing option; Now Mac computers and even Windows computers can recognize your computer on a local network. If you connect your Mac to another Apple computer running the latest OS using file sharing, your PC will try to automatically use the SMB protocol to establish a. File Sharing on Your Mac. The most common network activity (beyond email and web surfing) is file sharing. Your Mac comes ready to share files using several popular protocols—AFP (Apple Filing Protocol) and SMB (Simple Message Block) are the most popular. To share a folder with another user, follow these steps: Choose Apple→System Preferences (or click the System Preferences icon in the Dock). In the System Preferences window, click the Sharing icon. Trumpf bosch cc200 manual. Click File Sharing in the list of services on the left.
| 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.
- open the Sharing Preferences
- enable File Sharing
- add the folder you want to share, and
- choose what users get to share it.
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.
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.
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.
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.
Here are a few more tips and suggestions related to your post:
Copying and Moving
Now you are ready to copy .. anything .. into the shared folder. IMPORTANT: You must copy .. and not merely move..
See my answer to an Apple Discussions posting for more detail about how permissions are set on copied items and why they don't change for moved ones: here. Moving an item won't change its permissions at all. Everything – POSIX owner, POSIX group, POSIX permission bits, explicit ACL entries, and inherited ACL entries – is preserved. This is because the item you're moving isn't really changing; it's not a copy.
Step 5 - Adding the ACL Entry
Again, this is a very good example, but the command you've provided is best executed on an empty folder, because it will only set the ACL for that folder. The syntax chmod +a PATH only applies the new entry to the folder or file in question. Since the applied entry also contains the file_inherit and directory_inherit controls, it will be copied onto new items that arrive within the parent. New items includes newly-created files and folders or items that you copy there. Hence, the ACL entry set on the parent (Shared) will be inherited to new or copied items only.
But what if your parent folder (Shared) already has items in it that you want to make available to others? Or, what if you just want to move your iTunes Library there without actually having to duplicate it? You can do this, but you have to move it there then apply chmod with an extra option: -R. The -R flag means 'recursive,' and it tells chmod to apply the same ACL to the parent and any existing (e.g. already-moved) items. Pretty neat. Here's the syntax for reference:
--Gerrit
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?http://www.macworld.com/article/50643/2006/05/junedigitalphoto.html
and here:
http://ad.hominem.org/log/2005/07/acl.php
And Sandbox is an excellent tool for overcoming Leopard's obvious shortcomings in managing ACLs.
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.
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.
sudo. Also, I was able to execute step 3 with a simple
chgrp friday Fridayand custom access seemed to be properly granted thereafter.
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.
- open the Sharing Preferences
- enable File Sharing
- add the folder you want to share, and
- choose what users get to share it.
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.
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.
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.
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.
Here are a few more tips and suggestions related to your post:
Copying and Moving
Now you are ready to copy .. anything .. into the shared folder. IMPORTANT: You must copy .. and not merely move..
See my answer to an Apple Discussions posting for more detail about how permissions are set on copied items and why they don't change for moved ones: here. Moving an item won't change its permissions at all. Everything – POSIX owner, POSIX group, POSIX permission bits, explicit ACL entries, and inherited ACL entries – is preserved. This is because the item you're moving isn't really changing; it's not a copy.
Step 5 - Adding the ACL Entry
Again, this is a very good example, but the command you've provided is best executed on an empty folder, because it will only set the ACL for that folder. The syntax chmod +a PATH only applies the new entry to the folder or file in question. Since the applied entry also contains the file_inherit and directory_inherit controls, it will be copied onto new items that arrive within the parent. New items includes newly-created files and folders or items that you copy there. Hence, the ACL entry set on the parent (Shared) will be inherited to new or copied items only.
But what if your parent folder (Shared) already has items in it that you want to make available to others? Or, what if you just want to move your iTunes Library there without actually having to duplicate it? You can do this, but you have to move it there then apply chmod with an extra option: -R. The -R flag means 'recursive,' and it tells chmod to apply the same ACL to the parent and any existing (e.g. already-moved) items. Pretty neat. Here's the syntax for reference:
--Gerrit
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?http://www.macworld.com/article/50643/2006/05/junedigitalphoto.html
and here:
http://ad.hominem.org/log/2005/07/acl.php
And Sandbox is an excellent tool for overcoming Leopard's obvious shortcomings in managing ACLs.
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?
How To Share Files For Different Users On Mac Os Catalina
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.
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.
sudo. Also, I was able to execute step 3 with a simple
chgrp friday Fridayand custom access seemed to be properly granted thereafter.
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.
Connect To Windows Share From Mac
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.