rfs − remotefs client
rfs host:remote_path mountpoint [options]
General
options:
−o opt,[opt...]
Mount options
−h, −−help
Print help
RFS options:
−q
Suppress warnings
−v
Print version
−l HOST
List available exports on specified HOST
−o username=NAME
Auth username
−o password=FILENAME
Filename with password for auth
−o port=PORT
Port which the server is listening to
host can be either server’s host name or its IP address. remote_path is the path of the directory which is exported on the server. If server’s exports file contains the line: /exports/alice alice () then remote_path must be /exports/alice.
−o username=NAME User name for rsfd. If UGO option is enabled for a particular export, this name should also be registered in server’s user login base.
−o password=FILENAME This plain-text file must contain the password for accessing the remote directory.
Note that for security reasons this file should only be readable by its owner.
The command line for mounting the remoteresource may look like:
rfs -o username=alice,password=./pwd-home 192.168.1.2:/exports/alice ./mnt/
There are also a lot of options which are offered by FUSE. FUSE has been built for many kinds of file systems and not every option will work with remotefs. Some of the FUSE options may result in errors or decrease the performance of remotefs.
However, -okernel_cache may increase transfer speed for remotefs.
Please avoid usage of -odirect_io as it will most likely lead to errors.
Remarks
Solaris: In order to mount remote directory with
remotefs you must have FUSE access rights, see user_attr(4).
This can be done by setting the "FUSE File System
Management" rights with the user and group
administrations tools,
FreeBSD: Mounting of FUSE based file system is allowed if vfs.usermount is set to 1 via the sysctl command. This can be configured within the file /etc/sysctl.conf (add the line "vfs.usermount=1"). You can unmount your private mountpoint with the umount command.
Official recommendation for remotefs is to keep it away from untrusted networks.
Please consider this advice seriously.
If /etc/passwd and /etc/group file on the client and the server are not identical, the displayed name for unknown user and group will default to nobody (username), nogroup or name of the primary group of the user on the client. In this case, access rights may differ from the ones reported by remotefs.
This actually means that remotefs may not know the real user or group the file belongs to, but in any case access is controlled by the server with its security setup.
For example:
The server has a file that belongs to remotefs:remotefs. There is neither a "remotefs" user nor a group on the client, so this file may be reported as nobody:nogroup. Even if a client’s user could access nobody’s files on his system, server won’t allow it, since the real owner of this file is the "remotefs" user.
Aleksey
Tulinov: aleksey_t@users.sourceforge.net
Jean−Jacques Sarton:
jjsarton@users.sourceforge.net
See remotefs project on SourceForge: http://remotefs.sourceforge.net/
GNU General Public License (GPL)
rfsd(8), rfspasswd(8), fstab(5)