[sshfs] sshfs mounted applications fail with "error loading shared libraries"

[Vasanth <vas...@gm...>]

Hi,

I am using sshfs to mount some Xilinx tools remotely. I am able to
read and write to the mounted file systems. However, when I run some
applications, I encounter shared library load errors from the
application. On digging deeper, it appears that open() system calls in
the application fail with an EPERM error. However, the files do have
valid permissions. Placing a local copy of the .so file and adding the
local path to LD_LIBRARY_PATH causes the application to proceed
further but then eventually fail with a similiar error on some other
DLL. Copying all the DLLs locally and running the application works
fine to completion. Some other applications work fine when run fully
remotely.

The error is always on the same .so file.

Here is the log from running sshfs with a -d flag (from the machine
that exports the file system)

<snip>
unique: 671, opcode: LOOKUP (1), nodeid: 4, insize: 55
LOOKUP /ISE9.2i/bin/lin64/libXst_Core.so
   NODEID: 105
   unique: 671, error: 0 (Success), outsize: 136
unique: 672, opcode: OPEN (14), nodeid: 105, insize: 48
   unique: 672, error: -1 (Operation not permitted), outsize: 16
</snip>

I have tried all the -o options supported by sshfs and one of them
seem to have any effect, except the -o use_ino flag. When using this
flag, the .so load error is not seen anymore, but other DLLs run into
a symbol lookup error. I have also tried the -o workaround=all option.

Here are some details of my machine configuration:

<snip>
uname -a
Linux domU-12-31-38-00-5D-71 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36
SAST 2007 x86_64 x86_64 x86_64 GNU/Linux
cat /proc/version
Linux version 2.6.16.33-xenU
(ro...@do...ernal) (gcc version 4.1.1
20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007
</snip>

The machines are Fedora Core 6 images on a Xen virtual environment.

Here are the FUSE version details:

<snip>
sshfs -V
SSHFS version 1.8
FUSE library version: 2.7.0
fusermount version: 2.7.0
using FUSE kernel interface version 7.8

dmesg | grep fuse
fuse init (API version 7.6)

</snip>

What could be going wrong? Is there anything I can try to workaround
the problem?

thanks,
Vasanth