The bug can be left valid by changing it, properly, to refer to gvfs or perhaps just Nautilus. That is the logical request: support for NFS in Gnome, without care for the underlying library (gnomevfs vs gvfs).
What we want is for Avahi published NFS mounts, e.g.,
which results in a client system being able to see:
= eth0 IPv4 Home Directories Network File System local
hostname = [amitower.local]
address = [192.168.1.6]
port = [2049]
txt = ["path=/home"]
Yes, I have left out /etc/exports, as it isn't germaine to zeroconf -- the point of Bug #65048, which has been marked as a duplicate of this bug, The point is that we want Gnome to show us those (removable) media when they are available, and allow them to be mounted.
Upstream won't be fixing GnomeVFS (http:// bugzilla. gnome.org/ show_bug. cgi?id= 328107# c16).
The bug can be left valid by changing it, properly, to refer to gvfs or perhaps just Nautilus. That is the logical request: support for NFS in Gnome, without care for the underlying library (gnomevfs vs gvfs).
What we want is for Avahi published NFS mounts, e.g.,
<service-group> wildcards= "yes">Home Directories</name> _nfs._tcp< /type> 2049</port> record> path=/home< /txt-record>
<name replace-
<service>
<type>
<port>
<txt-
</service>
</service-group>
which results in a client system being able to see:
= eth0 IPv4 Home Directories Network File System local
hostname = [amitower.local]
address = [192.168.1.6]
port = [2049]
txt = ["path=/home"]
Yes, I have left out /etc/exports, as it isn't germaine to zeroconf -- the point of Bug #65048, which has been marked as a duplicate of this bug, The point is that we want Gnome to show us those (removable) media when they are available, and allow them to be mounted.