File Security: Writable No

Why would a file be flagged has "Writable: No" When the user has permission to modify the file?

Writable: No
Owner: Someuser
Group snet_mar
Permissions rwxrwxr-x

The user is within the snet_mar group and the person has read/execute permissions on the parent directories. Even if I do chmod 777 on the file, I still receive Writable: No.

Overview of the file Properties:

Basic Attributes:
Modified: Yes

File Security:
Writable: No
Owner: cran
Group: snet_mar
Permissions: rwxrwxr-x

Area Security:
Writable: No
Owner: rbur
Group: snet
Permissions: rwxrwxr-x

The user that is trying to import the file is within snet_mar (Primary group com_iwov) and they (the importing user) has read/execute all the way up the folder structure to the file.

The error I receive is "Error importing file Blah.pdf to TeamSite Server:

Error moving temp file /var/tmp/tmpAAwFayu6 to /.iwmnt/....... 13"

Where "......." is just some long path.

-[ Richie Rich ]-

Find more posts tagged with

Comments

JonathonG

I think this line points out your problem:

Area Security:
Writable: No

If the area isn't writeable by the user, then no file in that area will be writeable.

Is the user in the snet group? (The group for sharing for that workarea)

Jonathon
Independent Interwoven Contractor

RichieRich

I was thinking the same thing, but if the user has read access up to that folder and their group owns that folder, shouldn't they have write access to that folder?

The user isn't in the GFS because we have a folder that contains 8 regions. Each region will have access to their own folder to manage it and our current site is designed before hand to group them in the same folder.

Another problem is the GFS is snet which was designed to restrict only snet people to that branch. The people that will be maintaining the regions folder shouldn't have write access to *anything* except their own folder located under /regions/

e.g.,
/regions/MAR (Only MAR Personal)
/regions/WER (Only WER personal)

I was under the assumption the impression that once they were able to view that folder and had write access to that folder there should be a problem.

http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=20666&page=&view=&sb=&o=&vc=1#Post20666

-[ Richie Rich ]-

Migrateduser

Could this be related?

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

JonathonG

If you are not in the GFS for a workarea, you cannot edit files in that workarea....If you want to control access to particular areas for particular groups, you'll need to use OS permissions on the files/directories in the WA, not the GFS. The GFS is meant to limit who can do work in a given workarea. This allows isolation of work-in-progress.

HTH,

Jonathon
Independent Interwoven Contractor

RichieRich

Is this KB relevant to TeamSite 5.5.2?

Sorry if I didn't mention the TeamSite version before hand.

-[ Richie Rich ]-

RichieRich

John Thank you very much. I tried it out and it works fine.

The Administration Guide said *nothing* about this. (My TeamStie Admin guide is for 5.5.1 so I need to update it.)

10 Virtual Points to John.

I searched their support.interwoven.com site but didn't find anything in regards to this. Nice work.

-[ Richie Rich ]-

Migrateduser

Be sure you download the latest Admin guide (and other manuals). Many were improved for the 552 SP3 release. Much of the information still applies, even if you are not on that particular Service Pack.

https://support.interwoven.com/library/manuals/teamsite/teamsite.asp

regards,

lissa