desktop-packages team mailing list archive

[ossjunkie <435719@xxxxxxxxxxxxxxxxxx>]

@John: Did you take a look at the patch i have proposed, it wouldn't
need a big adjustment for your needs.

Anyhow great that there is some interest in this topic. Would be great
if we could bring a patch to the package in time for the precise
release.

What the patch is lacking beside John's suggestion is a routine for the
case where NFS isn't present anymore, so i works back and forth.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/435719

Title:
  gvfs-fuse fails to start on NFS mounted homes

Status in GVFS:
  New
Status in “gvfs” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: gvfs

  gvfsd usually start a gvfs-fuse-daemon for GVFS mounts, which fuse-
  mounts to $HOME/.gvfs. This fails if the home directory resides on an
  NFS share with root squashing enabled. Thus, users in a
  corporate/networked environment with such NFS homes cannot use gvfs
  effectively, since a lot of applications rely on the fuse mount.

  For those unfamiliar with NFS, root squashing means the local UID 0 is
  mapped to the anonymous/nobody UID on the remote system when it tries
  to access the NFS share. Since home and subdirectories have
  permissions 0700, $HOME/.gvfs cannot be accessed by root in this case.
  This makes the mount() call of gvfs-fuse-daemon fail (verifiable with
  'strace gvfs-fuse-daemon /home/user/.gvfs').

  There are two solutions to this:
  a) disable root squashing
  b) move the .gvfs directory somewhere else

  a) is not a good choice for security reasons. b) seems not to be
  possible at the moment. I looked at the sources for the current
  (jaunty and karmic) gvfs package and found

  mount->fuse_mountpoint = g_build_filename (g_get_home_dir(), ".gvfs",
  fs_name, NULL);

  in daemon/mount.c. Even though gvfs-fuse-daemon can be called with any
  path you like, it looks like the path which gfvsd uses for the call is
  hard-coded. I was able to symlink /home/user/.gvfs to /tmp/.gvfs, and
  this works. But I am not sure if that is a good solution.

  I would like to ask the package maintainers to a) include a README.NFS
  in the package which points out the problem and workaround (I can
  write one if you like) and b) forward this bug upstream to the right
  place, so the path with which gfvs-fuse-daemon gets called can be
  configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/435719/+subscriptions