Free nfs software for linux

Linux NFS Utilities are NFS utilities for Linux NFS clients and servers.
Main features:
- NFS Versions 2, 3, and 4 are supported on 2.6 and later kernels.
- NFS over UDP and TCP on IPv4 are supported on the latest 2.4 and 2.6 kernels.
- Linux NFS clients and servers have been tested against many non-Linux implementations.
- Since version 1.0.1 of the NFS utilities tarball has changed the server export default to "sync", then, if no behavior is specified in the export list (thus assuming the default behavior), a warning will be generated at export time.
- If you plan to deploy NFS extensively, consider subscribing to one of these mailing lists: NFS Mailing List, or the AutoFS Mailing List. Before reporting problems, you should search for similar issues in the searchable mail archive. Another searchable archive for NFS, supported by Google, is here. The searchable mail archive for AutoFS is here.
- A useful set of generic NFS references includes the following:
- - "NFS Illustrated," by Brent Callaghan; Addison-Wesley, 2000.
- - "Managing NFS and NIS, 2nd edition," by Hal Stern, Mike Eisler, Ricardo Labiaga; OReilly, 2001.
- - "Linux NFS and Automounter Administration," by Erez Zadok; Sybex, 2001.
- - "Using the Linux NFS Client with Network Appliance Filers," by Charles Lever; Netapp TR-3183, 2004.
- - "Mike Eislers NFS blog."
- - "Eric Kustarzs blog."
- - "NFS version 4 home page."
- - Finally, the "linux.org online library" has many references.
Quick setup client guide
1. Acquire and install a recent distribution of Linux.
2. Set up your /etc/exports file (man exports for details).
3. Consult your distributions documentation to determine which /etc/init.d start-up script is used to start your server. Start NFS services by invoking this script as root, using the "start" parameter. Consider adding this script to the list of scripts that are automatically run at system start-up. (Red Hat uses the chkconfig command for this purpose).
4. Read the NFS How-To for advice on tuning and securing your server.
Quick Client Setup Guide
1. Acquire and install a recent distribution of Linux. To enable NLM lock recovery, ensure your clients host name, as returned by uname -n, matches the host name returned by DNS.
2. The NLM protocol is handled by an in-kernel service in modern kernels, but the user-level rpc.statd program must be running to enable NLM lock recovery. Consult your distributions documentation to determine which /etc/init.d start-up script is used to start it. Start the NSM daemon by invoking this script as root, using the "start" parameter. Consider adding this script to the list of scripts that are automatically run at system start-up. (Red Hat uses the chkconfig command for this purpose).
3. Create the directories on your client where you will mount the NFS shares.
4. Add entries in /etc/fstab corresponding to your mount points (man nfs for details).
5. Use mount -a -t nfs to mount the NFS shares.
6. During system boot-up, most distributions automatically mount NFS shares that are listed in /etc/fstab. If yours doesnt, check your distributions documentation for instructions on how to configure your client to do this.
Enhancements:
- The "mount.nfs" command was added, since the nfs mount functionality is being migrated from util-linux to nfs-utils.
- Substantial changes to were made statd. Various pieces of old code were removed.
- Lots of bugfixes and improvements were made.

TCFS project is a cryptographic network file system featuring group sharing of encrypted files. TCFS will encrypt your files before sending them to the file server and will decrypt them before they are read by the requesting application.

Because the encryption/decryption process takes place on the client host, no clean data will travel the network. This is particularly valid for the encryption key.

Recent advances in hardware and communication technologies have made possible and cost effective to share a file system among several machines over a local (but possibly also a wide) area network.

One of the most successful and widely used such applications is Suns Network File System (NFS).

NFS is very simple in structure but assumes a very strong trust model: the user trusts the remote file system server (which might be running on a machine in different country) and a network with his/her data. It is easy to see that neither assumption is a very realistic one.

The server (or anybody with superuser privileges) might very well read the data on its local filesytem and it is well known that the Internet or any local area network (e.g, Ethernet) is very easy to tap (see for example, Berkeleys tcpdump application program).
Impersonification of users is also another security drawback of NFS.

In fact, most of the permission checking over NFS are performed in the kernel of the client. In such a context a pirate can temporarely assign to his own workstation the Internet address of victim. Without secure RPC no further authentication procedure is requested. From here on, the pirate can issue NFS requests presenting himself with any (false) uid and therefore accessing for reading and writing any private data on the server, even protected data.

Given the above, a user seeking a certain level of security should take some measures. We propose a new cryptographic file system, which we call TCFS, as a suitable solution to the problem of privacy for distributed file system.

Dynamic Encryption Modules in TCFS:

The dynamic encryption module feature of TCFS allows a user to specify the encryption engine of his/her choiche to be used by TCFS. So you are not forced anymore to use what us (the developer) consider the best (i.e., more secure and efficient) encryption algorithm. The encryption engine must be given in the form of a Linux module and must conform to (the very simple) TCFS API for encryption module. Essentially, it must specify four functions:

1. An initialization function that is called by TCFS when the user pushes her key into TCFS.

Typically the initialization function takes as input the key and returns a pointer to a struct containing a the result of a preprocessing of the key to be used for the encryption and the decryption.

For the specific case of DES the initialization function computes the 16 48-bit subkeys, one for each round of DES.

2. An encryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and encrypts the data.

3. A decryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and decrypts the data.

The encryption and the decryption functions are called each time TCFS needs to read/write a block of data.

4. A cleanup function which performs whatever operation is needed before the key removed by TCFS.

Our work improves on Matt Blazes CFS by providing deeper integration between the encryption service and the file system which results in a complete transparency of use to the user applications.

Release 2.2 of TCFS includes the possibility of threshold sharing files among users. Threshold sharing consists in specifying a minimum number of members (the threshold) that need to be ``active for the files owned by the group to become available.

TCFS enforces the threshold sharing by generating an encryption key for each group and giving each member of the group a share using a Threshold Secret Sharing Scheme. The group encryption key can be reconstructed by any set of at least threshold keys.

A member of the group that intends to become active does so by pushing her/his share of the group key into the kernel. The TCFS module checks if the number of shares available is above the threshold and, if it is so, it attempts to reconstruct the group encryption key. By the properties of the Threshold Secret Sharing Scheme, it is guaranteed that, if enough shares are available, the group encryption key is correctly reconstructed.

Once the group encryption key has been reconstructed, the files owned by the group become accessible. Each time a member decides to become inactive, her share of the group encryption key is removed. The TCFS module checks if the number of shares available has gone under the threshold. In this case, the group encryption key is removed from the TCFS module and files owned by the group become unaccessible.

The current TCFS implementation of the group sharing facility requires each memeber to trust the kernel of the machine that reconstructs the key to actually remove the key once the number of active users goes below the threshold. Future implementations will remove this requirement by performing the reconstruction of the key in a distributed manner.

The rcf Linux Firewall (aka rc.firewall) is an ipchains-based firewall. With support for over 50 network service modules (including vtun, dhcp, nfs, smb, napster, proxies, online games, etc.), masquerading, port forwarding, and ip accounting. All services are self-contained modules which can be prioritized in the ipchains stack.

Protections include spoofing, stuffed routing/masquerading, DoS, smurf attacks, outgoing port scans, and many more. rcf also supports unlimited public, private (masqued), dmz, and mz (non-masqued) interface and their subnets.

Access rules are defined per interface and dmz/mz server "clusters". rcf is compatible with Red Hat, Slackware, Debian, Linux Router Project (LRP), and many other distros.

Provided several updates, including: contributing 260-spop3-servers, 220-winvnc-servers, 620-arcserve-hosts, and netstorm (online game) modules, fixed a typo in 530-snmp-clients, fixed cluster handling in 030-pptp-clients and 030-pptp-servers, patched service_rules.sh to allow private IPs on DMZ interfaces, added missing rules to allow traffic from public interfaces to the DMZ, added the
--refresh-interfaces command line option, and fixed the jump rule problem which prevented private IPs from connecting to public interface IPs.

Squashfs project is a compressed read-only filesystem for Linux. Squashfs is intended for general read-only filesystem use, for archival use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed.
The filesystem is currently stable, and has been tested on PowerPC, i586, Sparc and ARM architectures.
Main features:
- Data, inodes and directories are compressed.
- Squashfs stores full uid/gids (32 bits), and file creation time.
- Files up to 2^32 bytes are supported. Filesystems can be up to 2^32 bytes.
- Inode and directory data are highly compacted, and packed on byte boundaries. Each compressed inode is on average 8 bytes in length (the exact length varies on file type, i.e. regular file, directory, symbolic link, and block/char device inodes have different sizes).
- Squashfs can use block sizes up to 64K (the default size is 64K). Using 64K blocks achieves greater compression ratios than the normal 4K block size.
- File duplicates are detected and removed.
- Both big and little endian architectures are supported. The mksquashfs program can generate filesystems for different endian architectures for cases where the host byte ordering is different to the target. This is useful for embedded systems.
Enhancements:
- This release is a major improvement, and Squashfs filesystems can now be exported via NFS.
- Squashfs-tools have also seen some improvements: Unsquashfs can now extract 2.x filesystems; and Mksquashfs now displays a progress bar.
- There are other smaller improvements and bugfixes.

Openfiler is a intuitive, powerful browser-based network storage software distribution. Openfiler delivers file-based Network Attached Storage and block-based Storage Area Networking in a single framework.
Openfiler sits atop of CentOS Linux (which is derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor). It is distributed as a stand-alone Linux distribution. The entire software stack interfaces with third-party software that is all open source.
File-based networking protocols supported by Openfiler include: NFS, SMB/CIFS, HTTP/WebDAV and FTP. Network directories supported by Openfiler include NIS, LDAP (with support for SMB/CIFS encrypted passwords), Active Directory (in native and mixed modes) and Hesiod. Authentication protocols include Kerberos 5.
Openfiler includes support for volume-based partitioning, iSCSI (target and initiator), scheduled snapshots, resource quota, and a single unified interface for share management which makes allocating shares for various network file-system protocols a breeze.
Main features:
Powerful block storage virtualization
- Full iSCSI target support, with support for virtual iSCSI targets for optimal division of storage
- Extensive volume and physical storage management support
- Support for large block devices
- Full software RAID management support
- Support for multiple volume groups for optimal storage allocation
- Online volume size and overlying filesystem expansion
- Point-in-time snapshots support with scheduling
- Volume usage reporting
- Synchronous / asynchronous volume migration & replication (manual setup necessary currently)
- iSCSI initiator (manual setup necessary currently)
- Extensive share management features
Support for multiple shares per volume
- Multi-level share directory tree
- Multi-group based access control on a per-share basis
- Multi-host/network based access control on a per-share basis
- Per-share service activation (NFS, SMB/CIFS, HTTP/WebDAV, FTP with read/write controls)
- Support for auto-created SMB home directories
- Support for SMB/CIFS "shadow copy" feature for snapshot volumes
- Support for public/guest shares
- Accounts management
Authentication using Pluggable Authentication Modules, configured from the web-interface
- NIS, LDAP, Hesiod, Active Directory (native and mixed modes), NT4 domain controller
- Guest/public account support
- Quota / resource allocation
Per-volume group-quota management for space and files
- Per-volume user-quota management for space and files
- Per-volume guest-quota management for space and files
- User and group templates support for quota allocation
- Other features
UPS management support
- Built-in SSH client Java applet
- Full industry-standard protocol suite
CIFS/SMB support for Microsoft Windows-based clients
- NFSv3 support for all UNIX clients with support for ACL protocol extensions
- NFSv4 support (testing)
- FTP support
- WebDAV and HTTP 1.1 support
- Linux distribution back-end for any other customizations
- Open source provides you the power to modify and deploy software if you want to do so
Enhancements:
- Updated to kernel 2.6.17. iSCSI CHAP authentication has been added.
- OpenLDAP, Bacula, rsnapshot, and open-iscsi tools have been added.
- Hardware support has been added.
- ATA-Over-Ethernet support (initiator) has been added.
- SUpport for JFS, XFS, and Reiserfs has been added.

Autofs NG is a Linux automounter that is intended to be completely interoperable with autofs implementations on other Unix platforms. As such, it supports some features that the current Linux automounters do not.
This includes direct mounts, /net (--hosts access), lazy mounting and unmounting of hierarchical multimounts, and browsing. Autofsng also supports the usual indirect map support available elsewhere.
Maps are supported from flat files, executable maps, NIS maps, NIS+ maps, LDAP maps, and hesiod (DNS) filsys namespace.
AutofsNG was originally developed at Sun Microsystems, but has been cancelled as a project. Fortunately, it has been released as GPL, so I am continuing its development in my spare time.
Enhancements:
- Initscript fixup for path to /proc/mounts
- We no longer update /etc/mtab because the kernel does all unmounting. Current recommendation is to symlink /proc/mounts to /etc/mtab if you want to see the what is actually mounted with calling mount
- Fixed SuSE/LSB initscript issue where ypbind wasnt neccesarily started before autofsng.
- Added an RPM .spec file to the tree.
- Fixed initscript install
- Fixed possible crash when using the -hosts map.
- Redimentary mount option translation. Currently translates the common Solaris NFS mount options to Linux specific ones. Hard-coded.
- Initscript fixups for unknown systems (Debian in particular)
- Fixed a bug where the -hosts map would return duplicate map offsets, which is a semantic error for usual entries.