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

Stale NFS File Handles in TS 6.7.1 SP1 on 32 Bit Linux

gmiglior

We're running TeamSite 6.7.1 SP1 on 32 bit linux which is using UVFS to NFS mount the TeamSite filesystems. We notice that at times users would be importing/scp'ing/sftping files and they wouldn't reflect the updates, and if you viewed the files via the command line, we received an error saying "Cannot stat -- Stale NFS file handle."

We thought that this could be related to our users uploading the files to TeamSite using different methods, and it's corrupting something someplace. Sometimes we are able to rename the file to something else via the TeamSite UI, delete the old one, submit it, and rename the file back. Other times, this does not work, and corruption goes all the way up to the folder or branch level.

Is anyone else experiencing issues like this?

Find more posts tagged with

Comments

nipper

This is a very generic error message, so you may want to dig deeper and see if any logs are updated which may point to the issue. It *sounds* like the issue is inconsistant so it works sometimes. Obviously then not an NFS version issue or driver not installed (2 common reasons to get that error)

gmiglior

The weird thing is - this doesn't come up in any logs except if you're trying to access the file that's broken, or a file within a directory that's broken...I've had support analyze log files a million times and they came up with nothing...

gmiglior

Yesterday with this happened, we found that marking the folder as "private" and unmarking it seemed to fix this issue.

Adam Stoller

The weird thing is - this doesn't come up in any logs except if you're trying to access the file that's broken, or a file within a directory that's broken...I've had support analyze log files a million times and they came up with nothing...

Is your backing store on the actual TS server - or is it mounted from a network storage device (like a NetApp box)?

If the former, it seems strange that you would get stale NFS handles unless someone somehow screwed around with the /iwmnt and/or /.iwmnt - which are the two local NFS mount points for TS.

If the latter - it sounds like a network "hiccup" in which the connection between the TS server and the backing store was interrupted at some point - and usually the only way to fix that is to completely stop and restart TS - although a reboot of the TS server may not be necessary, it's still probably a good idea to do so in such cases.

gmiglior

Our content stores are SAN storage, not local storage. With Linux, there's no /.iwmnt filesystems.

I would think that if there were network hiccups between TeamSite and the storage, wouldn't the entire NFS mounted filesystem be stale? In this case, it's only certain files or folders, and the issue ONLY occurs when two people update files using different methods of SFTP.

We never had this issue on Solaris... =(

jed

We never had this issue on Solaris... =(

No comment Smiley Happy

Adam Stoller

Our content stores are SAN storage, not local storage. With Linux, there's no /.iwmnt filesystems.

I would think that if there were network hiccups between TeamSite and the storage, wouldn't the entire NFS mounted filesystem be stale? In this case, it's only certain files or folders, and the issue ONLY occurs when two people update files using different methods of SFTP.

I think only the files that were being interacted with during the "hiccup" would leave stale NFS handles - the rest of the system would appear fine.

I'm pretty sure you'd have to at least restart TS (stop/start) if not reboot the TS server itself - in order to clear up all the stale handles. (I'm willing to be proved wrong on this)

gzevin

No comment

I have a few comments. But they all contain words that will be censored. Smiley Very Happy

gzevin

We're running TeamSite 6.7.1 SP1 on 32 bit linux

a bit unrelated question - which hardware are you running it on? I mean do you have a 64-bit server that has 32-bit OS on it or you managed to get a 32-bit server ? really curious

gmiglior

it's 32-bit. Interwoven I don't think supported 64 bit at the time we upgraded. Not sure if they do now?

gzevin

it's 32-bit. Interwoven I don't think supported 64 bit at the time we upgraded. Not sure if they do now?

I was more interested in what is the real server. Because at the time 32-but servers were not available on the market.

Yes, 64-bit version is now available.

mrki

Hi,

do you still get the UVFS Error? We have exactly the same problems on the same environment (32 Bit Linux + TeamSite 6.7.2 + SAN Storage) and cannot get rid of the error Smiley Sad

The last time uvfs error occured was in dez 09, and then yesterday again.

Many thanks,
Mario

brizrobbo

I had this on a Solaris machine a few years ago with TS 6.5.0. Support couldn't fix it either. We solved it by upgrading to TS 6.7.1. My biggest suspect was the NFS loopback, but I still have no idea what caused it. :-(