Author Topic: NFS issues  (Read 5912 times)

leng

  • Community Member
  • Posts: 6
  • Hero Points: 0
NFS issues
« on: July 18, 2006, 04:20:32 pm »
Hi,
I've been using slickedit for some time (on windows and linux) and shortly after upgrading to v11 I started to have problems with the linux version in tagging NFS mounted files.  This was on SUSE 9.1 and after some thrashing around the problem went away.  However, I have now moved to Ubuntu 6.06 and it is back with a vengeance.  Basically slickedit gives me an access denied error whenever I try to edit an NFS mounted file (I can get the directory listing ok).

I've played with permissions and ownership but it makes no difference.  VI works ok :(

I found one reference here to NFS problems.  If there is any advice, workaround or prognosis I would be grateful.

Thanks

Kohei

  • Senior Community Member
  • Posts: 192
  • Hero Points: 25
Re: NFS issues
« Reply #1 on: July 18, 2006, 06:02:33 pm »
First, try starting SlickEdit (the "vs" binary) with a -sul option to see if the "access denied" message goes away.  This option disables the byte-range file locking that SlickEdit normally performs, which seems to hit the NFS locking bug under certain circumstances.

If you still continue to have issue even with the -sul option, please post the output of the following commands (or send it to support@slickedit.com if you don't want to post it here):

On the server that exports the filesystem,

Code: [Select]
cat /proc/fs/nfs/exports
cat /proc/version

On the client machine that mounts the filesystem,

Code: [Select]
cat /proc/version
/usr/sbin/rpcinfo -p
/usr/sbin/rpcinfo -p <server name>
cat /proc/mounts

to help us reproduce it.

Also, if the problem happens only infrequently, does it tend to happen with files of any size, or does it tend to happen with larger files?

Do you have nfslock running both on the client and the server?  To check the status of nfslock, run

Code: [Select]
/sbin/service nfslock status
and check its output.

We have not been able to reproduce this problem on our end, but we are aware of this problem and are continuing to look into it.

On a general note, I would advise NOT to use 'async' option at all cost (very unlikely as it is off by default in all recent implementations of Linux NFS, but I still have to mention), and try to use TCP instead of UDP on both server and client.  NFS over UDP is more susceptible to packet loss and/or network latency, so at the expense of a slight performance loss, I would recommend NFS over TCP.  NFS over TCP is the default method in later versions of 2.4 and all of 2.6.  If you happen to use kernel 2.4.17 or something close to that version, pay extra attention to the protocol details of your NFS service because a lot changed during that version.

HTH,
Kohei
« Last Edit: July 18, 2006, 06:30:08 pm by Kohei »

leng

  • Community Member
  • Posts: 6
  • Hero Points: 0
Re: NFS issues
« Reply #2 on: July 19, 2006, 08:44:26 am »
vs -sul fixed it.

Thanks for the prompt reply - it was getting extremely frustrating!

If the command outputs you requested would be useful I can post them, but it sounds as if you know what is causing this particular problem.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3578
  • Hero Points: 229
Re: NFS issues
« Reply #3 on: July 19, 2006, 01:40:34 pm »
Starting with V12, SlickEdit will ignore errors returned by locking.  At the moment, its not a big deal if SlickEdit can't place a lock on a file.

Kohei

  • Senior Community Member
  • Posts: 192
  • Hero Points: 25
Re: NFS issues
« Reply #4 on: July 19, 2006, 09:23:10 pm »
Quote
If the command outputs you requested would be useful I can post them, but it sounds as if you know what is causing this particular problem.
You don't need to post the outputs if the -sul option worked for you (as you correctly guessed).  The outputs are mainly for a case where the -sul option didn't work, because we would be dealing with a different kind of NFS problem in such case.

Kohei

garion911

  • Senior Community Member
  • Posts: 184
  • Hero Points: 13
Re: NFS issues
« Reply #5 on: July 22, 2006, 09:56:13 pm »
Just an additional comment..

the -sul flag also fixed a similar issue on a smb mount filesystem on OSX..

Is there anyway to make this the default in OSX (since it gets fired up by that little Slickedit.app file?)


SlickEdit Support

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 232
  • Hero Points: 22
Re: NFS issues
« Reply #6 on: July 24, 2006, 02:59:08 pm »
Try opening your vslick.ini file and adding this line:

VSLICK=-sul

Your vslick.ini file will be in your config directory which can be found by going to Help > About SlickEdit.  This should invoke SlickEdit with the -sul command.  If you would like to learn more about setting Environment Variables in vslick.ini please go to Help > Contents > Appendix > Environment Variables.

John H.

  • Community Member
  • Posts: 22
  • Hero Points: 0
  • Systems and kernel programmer
Re: NFS issues
« Reply #7 on: August 24, 2009, 06:38:45 pm »
I have been struggling to make this work on SlickEdit 14.0.2.2, on Mac OS X. There is no vslick.ini, and no matter where I create one, I can't seem to get the -sul to take effect.

At the moment, I've hacked around it by invoking SlickEdit from the xterm Window. This is ugly.

So, two things:

1. This probably should be the default behavior for SE on Mac OS X.

2. I wish vslick.ini already existed on Mac OS X, as it would take the guesswork out of setting options.

3. How do I set this option correctly??

thanks!

rajkej

  • Senior Community Member
  • Posts: 250
  • Hero Points: 8
Re: NFS issues
« Reply #8 on: August 25, 2009, 01:20:11 pm »
I've only been successful with the -sul on OSX when using NFS. I had to change my UID on my Mac to match that on my server and I'm using the vslick.ini file in the following path:

~/Library/Application\ Support/SlickEdit/14.0.2/vslick.ini

My vslick.ini contents are:

[Environment]
VSLICK=-sul

This does not work for SMB mounts nor AFS mounts, only NFS. For AFS mounts, it helps but there are some operations that still don't work properly. Almost like the -sul option is ignored by some portions of slick edit. From what I recall, things like the debugger and the make system fail to work but file edits are ok. For SMB, I can't get that to work at all for some reason. Trying to open a file silently fails the request in most cases. I see file open errors when using the old open dialog but not when using smart open (could be the opposite, its been a while and I can't recall exactly which showed the error message).

HTH,
Russ

SlickEdit Support

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 232
  • Hero Points: 22
Re: NFS issues
« Reply #9 on: August 25, 2009, 04:35:17 pm »
You can also start SlickEdit from the X11 command line with the -sul option:

slickedit/bin/vs -sul