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; } } }

/iwmnt gives intermittent 'No permission'

RonaldV

Hi,

we have this strange problem where if you try to access file under /iwmnt you'll have 'No permissions' message. This is intermittent and last only a few seconds. After this the file is accessible again.

The same thing does NOT happen when you access the file via /.iwmnt.

We use ts-groups to set access but I'm not sure whether this is relevant for this problem.

Ts65Sp1 on Sol8.

Have others seen the same problem?

Cheers, Ronald

Find more posts tagged with

Comments

Frederik

Dag Ronald ;-)

recommend you read
http://devnet.interwoven.com/forums_vb/showthread.php?t=14980&forumid=11
(especially posts 5-7, thread is called "16-Group Unix Limit")

http://devnet.interwoven.com/forums_vb/showthread.php?t=16605&forumid=11&highlight=iwmnt+caching

or do a search on "iwmnt caching".

Adam Stoller

Hi,

we have this strange problem where if you try to access file under /iwmnt you'll have 'No permissions' message. This is intermittent and last only a few seconds. After this the file is accessible again.

The same thing does NOT happen when you access the file via /.iwmnt.

We use ts-groups to set access but I'm not sure whether this is relevant for this problem.

Ts65Sp1 on Sol8.

Have others seen the same problem?

Cheers, Ronald

Are you trying to access it after it has been submitted? If so - you're running into the caching feature of TS - where the modified file exists in the /.iwmnt (non-cached mount point) and is in the process of being flushed to the cached mount point (/iwmnt) during that window of time (seconds if not less, I would imagine) you will not be able to access the file from the cached mount point.

This is usually an issue with regard to OpenDeploy on Unix where you need to specify the non-cached mount point in your source area path specification.

RonaldV

This happens mostly (but not only) with 'stable' files, meaning files that have not changed in ages.

In our iw.cfg: map_secondary_to_primary_gid=yes

Does this give you any hints?

Adam Stoller

This happens mostly (but not only) with 'stable' files, meaning files that have not changed in ages.

In our iw.cfg: map_secondary_to_primary_gid=yes

Does this give you any hints?

Not specifically - though I do recall that Interwoven generally recommended against using this unless absolutely necessary - and as of 6.5 with the introduction of TS Groups - the recommendation is -- if you have to be a member of more than 15 groups - then you should use TS Groups instead of OS Groups because TS Groups do not have that limitation, and therefore you would be able to get rid of the map_secondary_to_primary_gid issue.

Alternatively - make use of the chmod g+s and submit.cfg functionality to ensure that the groups of the files created within TeamSite match the desired group.

Frederik

huh ;-)
this thread taught me something new... I'll describe what I learned (a bit lengthy, but if you're curious, bear with me)

I had never worked with TeamSite groups before, because I didn't like the concept too much, and I was wary of implementation quirks.

Most of what I know about TS groups, I got from a very old 7-page thread in 2004, where Sunil first explained the TS Groups concept in an announcement for the then upcoming 6.5. I also heard of some bugs in the first implementation (e.g. not working well with iwmigrate, IIRC).

Anyway, I looked into this, because the problems of Ronald remind me tremendously of the issues that come up by combining

iw.cfg: map_secondary_to_primary_gid=yes

and

/iwmnt

, and that I'm very familiar with. But then there's ghoti insisting it's not that. Smiley Wink

Well, yeah, it's not *that*, but it's very similar. It's due to dynamically mapping TS Groups to NFS, and then having them (incorrectly) cached on /iwmnt in a multi-user multi-tasking environment.

When using TeamSite global groups, the NFS interface has to play a trick to stay NFS / Unix compatible.

Consider a scenario (tested on Solaris 9, TS 6.5 sp2). tsgrp01 is a TeamSite Group, with one member: usr1. iwglobal is an OS group without members, created by TS installer.

$WA/tsfile => owner usr1, group tsgrp01, permissions rw-rw-r--

usr1 does in his shell:

$ cd $WA
$ ls -l
-rw-rw-rw-   1 usr01 iwglobal      155 Dec  4  2006 tsfile.txt

usr2 does in his shell:

$ cd $WA
$ ls -l
-rw-rw-r--   1 usr01 iwglobal      155 Dec  4  2006 tsfile.txt

so, on NFS level, the access is "opened up" by giving "other" write access, IF the user that asks for the file stats is considered to have write access through the teamsite group.

But if you access these over the cached mount /iwmnt, then the file stats are cached for about 60 seconds (by default).

Let usr2 first do this:

[usr02@tshost]:/iwmnt/test/main/WORKAREA/wa$ date; ls -l tsfile.txt
Tue Feb  5 10:34:38 MET 2008
-rw-rw-r--   1 usr01    iwglobal     155 Dec  4  2006 tsfile.txt

And then usr1 does this immediately after: (I did this every second or so, just abbreviated results)

[usr01@tshost]:/iwmnt/test/main/WORKAREA/wa$ date; ls -l tsfile.txt
Tue Feb  5 10:34:41 MET 2008
-rw-rw-r--   1 usr01   iwglobal     155 Dec  4  2006 tsfile.txt
...
[usr01@tshost]:/iwmnt/test/main/WORKAREA/wa$ date; ls -l tsfile.txt
Tue Feb  5 10:35:11 MET 2008
-rw-rw-r--   1 usr01   iwglobal     155 Dec  4  2006 tsfile.txt
...
[usr01@tshost]:/iwmnt/test/main/WORKAREA/wa$ date; ls -l tsfile.txt
Tue Feb  5 10:35:37 MET 2008
-rw-rw-r--   1 usr01   iwglobal     155 Dec  4  2006 tsfile.txt
...
[usr01@tshost]:/iwmnt/test/main/WORKAREA/wa$ date; ls -l tsfile.txt
Tue Feb  5 10:35:38 MET 2008
-rw-rw-rw-   1 usr01   iwglobal     155 Dec  4  2006 tsfile.txt

so, on /iwmnt, the cached mount, it takes up to a minute after the non-authorized user (usr02) took a file stat, for the authorized user (usr01) to get the correct file stat. Basically, the unauthorized user locked out the authorized user, on the cached mount. The reverse is also possible, I suppose, where the unauthorized user gets elevated authorization after an access by the authorized user.

So, again, my recommendation: scripts & shell users should use /.iwmnt. Only use /iwmnt if you know beyond doubt that you won't mess up security.