Newbie with TeamWork Problems!!

[Anonymous]

I apologize up front if this issue has been covered in the forum archives.

We are a small firm of three and have purchased AC 10 only three months ago.

We are having problems with Team Work. As we create a project to share (PLP) and each member saves and creates their respective (PLC) files, upon executing send/receive we receive messages that it cannot read the teamwork administration file. A second warning directs us to find (ADM) file manually, which doesn't work.

We are a new OSX firm with (2) 2.33 GHz Intel Core 2 Duo Mac Book Pro and (2) Mac Books networked to a 500 GB LaCie network hard drive, where the files reside.

The other weird thing is that while all of our individual PLC files are accessible, the original PLN appears corrupt as we receive a warning that the "plan file cant be read"

Please HELP!! we are sinking fast!!

[TomWaltz]

open Terminal

check what it is now: type umask in the Terminal
(will return 022 by default)


enter the following:

defaults write -g NSUmask 0

Then logout/reboot
Then check it in Terminal again: type umask in the Terminal
(should return 000 now)

[Karl Ottenstein]

In principal, it should be sufficient that each user is in the same group and that the group permissions are RW. Providing write access to all users is a bit of a security risk, unless you really want every user with access to your network to be able to write (and delete) the file.

Personally, I would never change the umask to full public access as Tom illustrated under any circumstances, but would only change permissions on a per file basis.

Aaron/Tom - have you had a problem with leaving 'other' protected and just making sure that the team members are members of a common group that has W permission?

Karl

PS The terms umask vs User Permissions along with others are just the Unix vs OS X 'friendly' terms for the same thing.

[Aaron Bourgoin]

In response to Karl's questiion about setting file permissions I have been too busy trying to make a really complex series of Temworked files communicate that I've been more firefighter than forensic crime scene investigator.

Will look into this some more as the permissions for some files I thought I had fixed are becoming read only again. The project is understaffed and so making the time to solve the ongoing issues is a challenge.

[Thomas Holm]

OK Thanks Tom,

I wasn't aware this means Terminal work - I'm too scared to change defaults that way when I really don't have any idea of what I'm doing. I guess Karl's advice is wise, and since this only is an issue whan you Save As new files, (permissions shouldn't change when you just save ongoing work) I think I'd better stick to only

change permissions on a per file basis

But i learn new things every day. That's why I'm here

[TomWaltz]

Karl wrote:
Aaron/Tom - have you had a problem with leaving 'other' protected and just making sure that the team members are members of a common group that has W permission?

With 50+ employees, we have people in different groups (admins, architects, graphics, etc), so the group does matter . For a smaller firm, it's probably not a big deal.

Thomas wrote:
I wasn't aware this means Terminal work - I'm too scared to change defaults that way when I really don't have any idea of what I'm doing. I guess Karl's advice is wise, and since this only is an issue whan you Save As new files, (permissions shouldn't change when you just save ongoing work) I think I'd better stick to only

It's one line in the Terminal. It won't hurt you. Besides, umask does affect files saved, not just new ones created.

[Karl Ottenstein]

TomWaltz wrote:
With 50+ employees, we have people in different groups (admins, architects, graphics, etc), so the group does matter.

Users can (should) belong to multiple groups to control access and avoid providing full public access.

Karl

[Thomas Holm]

TomWaltz wrote:
Besides, umask does affect files saved, not just new ones created.

But then why doesn't this Teamwork issue turn up all the time?

Is there some other way to fix it, like setting permissions on the server so that all files saved in this or that folder always get these specified permissions, regardless of the "umask" of the user? To me that seems like a more logical solution.

And I seem to recall there's an "inherit permissions" folder setting (through GUI, that is select folder > Get Info), which I think has been broke in a number of OSX releases, but that may be fixed now, haven't checked it lately.

[TomWaltz]

Karl wrote:

TomWaltz wrote:
With 50+ employees, we have people in different groups (admins, architects, graphics, etc), so the group does matter.

Users can (should) belong to multiple groups to control access and avoid providing full public access.

More importantly, why would we restrict access? Anyone signed into our network with access to the "Projects" volume is in the building and either has a valid login or a lot of unsupervised time to hack in.

[TomWaltz]

Thomas wrote:

TomWaltz wrote:
Besides, umask does affect files saved, not just new ones created.

But then why doesn't this Teamwork issue turn up all the time?

Is there some other way to fix it, like setting permissions on the server so that all files saved in this or that folder always get these specified permissions, regardless of the "umask" of the user? To me that seems like a more logical solution.

And I seem to recall there's an "inherit permissions" folder setting (through GUI, that is select folder > Get Info), which I think has been broke in a number of OSX releases, but that may be fixed now, haven't checked it lately.

It does turn up every time here, if the Sys Admin creates a new user and forgets to set the umask.

[Karl Ottenstein]

This article may be of interest to OS X users who were following the group access aspect of this thread and who have a peer-to-peer OS X network, rather than one using an OS X server:
http://www.peachpit.com/articles/article.asp?p=700592&seqNum=1&rl=1

Karl