nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Folder permissions in different Work areas in Unix

Maya_Pillai

We have Teamsite 6.5 on Unix(Sun OS 5.8). We have 4 workareas under a branch. Recently the business asked to change the folder permissions to a set of users.

We have created new Unix groups . I have changed the group (using chgrp) of around 45 folders in one workarea and set the permission level as 771 (using chmod).

The folder permissions and groups of other workareas remain the same as previous settings. Do we need to change the group and permissions in each work area?

Thanks
Maya

Find more posts tagged with

Comments

sumitk

There are two ways you can achieve this,

1. Change permissions for each workarea seperately

2. If content of 45 folders for which you have changed permissions are same across all workareas, then you can submit these 45 folders to STAGING and do "Get Latest" on these 45 folders in the remaining workarea.

Second option could cause problems if content is different.

set the permission level as 771 using chmod)

: how? Never heard of 771 in Unix.

Maya_Pillai

Thanks for quick response.

771 is rwxrwx--x permission

Thanks
Maya

Maya_Pillai

The user submitted all the folders from the workarea where I made the changes. And all the folders are back to the previous group now. She said, she has observed the conflict messages for a lot of them.

I am planning to do chgrp and chmod for all 45 folders in all the workareas. Do we need to have restart of app ?

I think, the conflict message is the reason for reverting to earlier groups.

Thanks
Maya

Adam Stoller

...
2. If content of 45 folders for which you have changed permissions are same across all workareas, then you can submit these 45 folders to STAGING and do "Get Latest" on these 45 folders in the remaining workarea.

I'm not sure this will work, as TS generally does not version directories so changes to the permissions on pre-existing directories tends not to get recorded in staging and thus may not be reflected in the other workareas when you do a get latest (if it works - great!, but if it doesn't - that's why)

In order to fix this (if it does behave the way I described) you will need to essentially re-create each directory by deleting (or renaming) them, submitting the deletions, then re-creating them with the proper permissions (you should fix up submit.cfg for this) and then re-submitting them - once that's done you should be able to see the changes reflected in all the workareas after doing a Get Latest.

Maya_Pillai

Thanks ghoti

Is there a way we can set the folder permissions in submit.cfg. As of now, I can see the options only for submitting the files.

For eg -

^/404/.*$" { perm=0775 gid=private }

If I changes this as below

"^/404/" { perm=0771 gid=nortreg }

Do we need to submit 404 as complete folder to get this permission executed ? In that case if there are content mismatches in files within, will the submission be successful?

If we can not do this way, I guess I have to change the file permissions within all the folders without touching the folders as such.

"^/404/.*$" { perm=0771 gid=nortreg }

Here, even if the folder is accessible , others are not able to read-write the files within.

Any thoughts ?

Thanks
Maya

Adam Stoller

Thanks ghoti

Is there a way we can set the folder permissions in submit.cfg. As of now, I can see the options only for submitting the files.

For eg -

^/404/.*$" { perm=0775 gid=private }

If I changes this as below

"^/404/" { perm=0771 gid=nortreg }

Do we need to submit 404 as complete folder to get this permission executed ? In that case if there are content mismatches in files within, will the submission be successful?

If we can not do this way, I guess I have to change the file permissions within all the folders without touching the folders as such.

"^/404/.*$" { perm=0771 gid=nortreg }

Here, even if the folder is accessible , others are not able to read-write the files within.

Any thoughts ?

Thanks
Maya

With regard to configuring permissions for folders in submit.cfg - please read the documentation - it's actually pretty decent in that regard.

With regard to fixing permissions on directories - please re-reaad my previous comment - if the directories have already been submitted with the incorrect permissions you cannot fix the permissions in staging unless you actually delete, submit, and then re-create, re-submit the directories with the correct permission settings.

Maya_Pillai

There will be 1000s of files in edit mode and locked . When we delete the folders and recreate ,what will happen to those files? Old links will be lost when we delete them . and since they are in edit and locked mode, we can't submit them as well from new folders. So, how do these kind of issues solved generally?

Also, this deletion and recreation in fact affect an entire website since we are dealing with all the folders in the most important branch. For Such a big task, what are the things we need to take care?

Thanks
Maya

Adam Stoller

There will be 1000s of files in edit mode and locked . When we delete the folders and recreate ,what will happen to those files? Old links will be lost when we delete them . and since they are in edit and locked mode, we can't submit them as well from new folders. So, how do these kind of issues solved generally?

Also, this deletion and recreation in fact affect an entire website since we are dealing with all the folders in the most important branch. For Such a big task, what are the things we need to take care?

Thanks
Maya

Nobody said it would be easy or fun. If you really need to fix the permissions on those directories you'll have to eventually kick everyone else off the system to take care of it.

One possibility, and I have no idea how well this will work: If you fix your submit.cfg correctly, cut an edition on the branch and then use iwmigrate to migrate the entire branch to a temporary second store, delete the original branch and then use iwmigrate to migrate it back to the original store (and then delete the temporary second store) - it might fix things up such that you get the correct permissions and keep all the history. This could be tested by only migrating the first two edition's worth to the temporary second store and checking the permissions on the directories in the temp_workarea (don't modify anything there, just look) - if it looks like the right thing happened - you should be good to go the rest of the way.

Depending on the number of files, editions, etc. this process could take anywhere from several hours to several days (or even weeks).

Also (assuming the above concept works) - when you are completely done migrating the content back into the original store - remember to run iwfsshrink on the original store as iwmigrate tends to cause massive amounts of duplicated content in the backing store.