Problem with Unix groups default of 16

Folks,
We are using Teamsite 5.5.2 on Solaris 8, we have multiple brnaches for different countries. The master account across these branches belongs to 32 unix groups. But default Solaris has a limit of 16 groups MAX. Please advice me how to work around this problem.

thanks

Find more posts tagged with

Comments

Migrateduser

Read this:

https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=1486

I have not had to use this before so I cannot comment specifically on the pros/cons of using the map_secondary_to_primary_gid.

--
Jed Michnowicz
Interwoven Technical Consultant

Migrateduser

We are currently running into the same problem. We have almost all of our users FTP content into TeamSite from their PCs. Many sites, many groups - same users in almost all of the groups. We are suddenly getting permission denied errors when everyone tries to FTP over the top of an existing file they appear to have every right to write over. We tried the map_primary_to_secondary_gid flag but it didn't solve our problem. We did notice that it seemed to work in the sense that when you looked at the files they appear to be owned by my primary group. It might solve your problems but it didn't solve ours. People are still getting permission denied errors when FTPing over the top of files. The weirdest part is if the file is deleted in TeamSite, they can then copy it over no problem. TeamSIte is so fun to work with sometimes.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

sma

What is the group limitation after setting the map_secondary_to_primary_gid=yes in iw.cfg?

Migrateduser

There is no group limitation. Read the description of map_secondary_to_primary_gid in the Admin Guide on pg. 144 (Solaris). It explains how it works.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

sma

Dave, thanks for the input. From the Admin Doc, it stated "if the map_secondary_to_primary option is turned on, it
maps the file’s group to the user’s primary group." So, does it mean that if a user's primary GID is different from the file 's GID, that user will not be able to modify that file even though the user's Secondary GID is the same as the file's GID?

Thanks.

Migrateduser

No, it's kind of complicated and is a very strange way around the problem. What happens is this. Let's say that you are a member of the group "foo" and a file is owned by someone else but group-owned by the "foo" group. The file permissions are set so that the group has read, write and execute permissions on the file. Let's also say that your primary group is "bar" and you belong to several other groups including "foo". When you look at the directory with a Unix ls command (I assume you are using Unix), instead of seeing the file owned by group "foo" it will likely appear that the file is owned by group "bar". That's a mirage, though. As far as you're concerned, you can edit the file no problem. But in reality the file is actually owned by group "foo" still. The ls output can be whacky - it sometimes shows your primary group, sometimes shows the actual group, and sometimes shows some other group. It is very confusing and inconsistent. However it appears to do the right thing, which is ignore the Unix 16 group limit and allow you to edit files as long as you have the correct permission and are a member of the correct group. It's all smoke and mirrors to me. If you want to see the actual group owner of any file, go into TeamSIte and do a File->File Properties on it.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

gzevin

most of my clients a cursing TeamSite for this feature....

this remapping confuses **** out of people and all the clients have disabled this.

Does 5.5.2 still exhibit this problem? I have not dealt with this issue on 5.5.2 as yet...

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Yes, 5.5.2 still exhibits this behavior. It even stung me yesterday as I went to modify the group permissions on a particular file a user was having trouble with and it took several iterations before I remembered that it was displaying my own primary group as owning the file and I didn't need to keep trying to reset the group ID. It's the strangest thing to deal with.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

13adam13

My experience has been that the map_primary_to_secondary_gid flag is only effective when trying to modify the files through the TeamSite (web) interface. If you need users to be able to work on the files (FTP, VI) on the operating system, rather than through the GUI, those users will need to have write permissions to those files from an OS perspective, not a Teamsite perspective.

I believe that without working through the GUI, TeamSite is not able to intervene and make the OS respect the later 16 groups that a person is a member of.

Migrateduser

What happens is that in order to allow access to the NFS client Interwoven changes the primary group of the file to the primary group of the user trying to access the file, if that user belongs to the owner group of the file. The problem starts happening when NFS caches this value and the next request by another user picks up this cached value. That also account for the weird behavior of "ls" command.

To bypass this is to access the iw-store through the uncached mount provided by Interwoven i.e. "./iwmnt/default/main..." rather then the cached mount i.e. "/iwmnt/default/main...". On the uncached mount NFS does not cache the file attributes and subsequent "ls" will return the same results.

Regards,
Raj