remotefs is a network file system designed for use with home NAS. Simple to use, few dependencies, reasonable security, completely in user space.
The reasons i've decided to make it are a) samba isn't working for me at all b) NFS is not working well for me c) sshfs is great, but not very fast.
So if you have troubles with samba and NFS (as I do), then you may be interested in remotefs.
It is provided with packages for i386/amd64 Debian-based systems, i386/amd64 Redhat-based systems, various OpenWrt-based systems (server only) and there are also Gentoo-ebuilds available.
See downloads section for the list of available packages.
Build scripts are available in SVN (http://svn.code.sf.net/p/remotefs/code/trunk/), so you could make packages for your plastform(s) if you wish so.
Note about OpenWrt packages
Most OpenWrt packages are marked as "experimental". That's because I don't have the actual hardware to make sure they are working.
I've built them with OpenWrt cross-compilers with great hope of being useful for OpenWrt users with platform other from MIPSEL.
I do have the hardware for MIPSEL, so that package should work just fine.
If some package(s) isn't working, i'd be appreciate if you e-mailed me about this (aleksey_t@users.sourceforge.net).
In this case i need to know the name of the package you used, your processor type ("cat /proc/cpuinfo") and OS version ("uname -a", probably).
How it works
Just file server
remotefs only translates the filesystem from remote host to your local host. To do that, the original file-owning user on the remote host is substituted by the local host user who has actually mounted an export via remotefs.
This is may look too simple, but this is enough for tasks performed by my home NAS.
My NAS is single-user and i'm always running remotefs as root on LAN interface (invisible from outside network).
So translating root's files' permissions to alex's permissions works just fine.
Server side has root access to filesystem and client side has alex's access, just as alex expects.
But if you need something more complex, like transferring a home directory from a remote host, you may define users on a per-export basis.
After an export is mounted on the local host, remotefs will lower its privileges to specified user (and/or group) and gain this user’s privileges on the remote host.
Since home directory usually has its user's permissions, you should not have any permission problems with this translation.
As an additional security measure, remotefs server could run connections with user other than root.
Use -u option to specify which user permissions every connection-handling process should aquire.
For example: rfsd -h 10.0.0.1 -u rfs.
Right after chroot(), rfsd will lower its priveleges to user rfs setting up rfs' groups.
Keep in mind that rfsd process will (possibly) lower its filesystem access privileges as well.
Main rfsd process still needs to be run as root to do chroot() properly.
UGO-compatible mode
If "ugo" (UGO stands for User-Group-Other) option is specified for some export, rfsd will log the user into the server’s OS.
It's like remote shell, but without the actual shell, just for file access.
For this mode server will report real files' owner and group.
See MAN pages (rfsd(8), rfs(1)) for possible side-effects.
rfsd's option -u is ignored for this mode.
Security notes
Official recomendation for remotefs is to keep it away from untrusted networks.
You normally setup rfsd to listen to local network.
If you absolutely need to use it over the Internet, you should at least firewall the connection with a specific IP-address.
Please consider this advice seriously.
BTW, rfsd will warn you about listening to interface that is not local and will refuse to run until -q option is provided, or local interface specified.
Mailing lists
remotefs-devel archive and subscription
remotefs-users archive and subscription
HTML MAN pages
rfs(1),
rfsd(8),
rfspasswd(8)
rfs_nssd(1),
rfsnsswitch.sh(1),
mount.rfs(8),
If you interested in the project or feel there's a feature missing, or have suggestions or any remarks,
we'd be glad to hear from you by e-mail at
aleksey_t@users.sourceforge.net
or jjsarton@users.sourceforge.net.
