.TH NCPFS 4
.SH NAME
ncpfs \- Network Control Protocol client
.SH SYNOPSIS
.B aux/ncpfs
[
.B -Dd
]
[
.B -s
.I srvname
]
[
.B -m
.I mntpnt
]
[
.B -k
.I keyparam
]
.I host
.SH DESCRIPTION
.I ncpfs
translates between the Novell Network Control Protocol (NCP)
and 9P, allowing 9P clients to mount file systems published by Netware servers.
.PP
The root of the mounted directory contains one subdirectory per Netware volume,
always in lower case, and some virtual file of mixed case which give server
and account information.
.PP
The options are:
.TP
.B -D
print all 9P messages.
.TP
.B -d
print all NCP packets.
.TP
.B -k \fI keyparam
lists extra parameters to be sent to \fIfactotum\fR to remove key ambiguity;
by default the remote servers's name is not included in the keyspec, thus assumes
the common enviroment where all Netware servers share their authentication.
.TP
.B -m \fImntpnt
set the mntpnt for the remote filesystem;
the default is
.BI /n/ \fI host \fR.
.TP
.B -s \fIsrvname
post the service as
.BI /srv/ srvname \fR;
the default is
.BI /srv/ \fI host \fR.
.SH "VIRTUAL FILES"
.PP
Several virtual files appear in the root of the mounted filesystem, These are
distinguished by the fact they have mixed case filenames; Netware volume
directory names are always lower case.
.PP
.TP
.B Who
Contains a list of the cunnectly connected users, one line per session,
with fields giving the user name, length, type and source address of the
connection.
.PP
.TP
.B Whoami
Gives miscellaneous info on the currently connected users account.
.PP
.TP
.B Groups
Lists the members of each user group. The entries consist of group name,
group id, and a comma seperated list of usernames.
.PP
.TP
.B Users
Lists user accounts giving the user name, user ID, Real name, telephone
number, department, and geographic location.
.PP
.TP
.B Printers
Gives the print queues known by the server.
.PP
.TP
.B Servers
Lists the other Netware servers known by this server.
.PP
.TP
.B Volumes
Enumerates the free and total space (in MBytes),
and free and total directory slots for each volume.
.TP
.B Session
This consists of the connected username, server's name, server's version,
the time slip between the local host and the server, the number
of users currently attached, and the Maximum Transfer Unit (MTU)
negioated.
.SH LIMITATIONS
.PP
No support for IPX is attempted, all NCP connections are made using Native
IP (NCP over a TCP/IP link).
.PP
No support for IPX signatures is attempted. If the security policy of the server
requires these then \fIncpfs\fR will not work as it stands.
.PP
Volumes to which the current user has no rights are given zero permissions
and a date of the 1st Jan 1970. All volumes may have only this metadata on early
Netware servers.
.PP
All group names reported are one of the groups the owner of the file or directory
belongs to. The group selection algorithm tries to find a meaningful group name,
enshuing \fBeveryone\fR and \fBnone\fR if possible.
.PP
File permissions are almost meaningless. Files are always either 0666 or
0444 mode depending on the Netare \fBReadOnly\fR attribute. Directories
are either 0777 or 0555 mode depending upon their inherited rights mask
(any restriction on the directories rights simply selects 0555 mode).
.PP
Netware permissions are relaxed a little, the
\fBReadOnly\fR attribute is removed when during file or directory,
rename or delete operations. This is necessary for CVS.
.PP
File and directory last access times have only day resolution and appear as midnight
(IE. the start) of the day in question; Modification times appear as expected.
.PP
No attempt has been made at support for 64 bit files. These are
only supported in a patched version of Netware 6.0.
.PP
Changing the owner or group via \fBwstat(2)\fR is not possible, and only
a single readonly file mode is supported:
.PP
.EX
flags = (r->d.mode & 0222)? 0: FAreadonly
.EE
.PP
Files are always opened as sharable, This is not the case for files held open
by other operating systems.
.PP
File sizes returned by \fBdirstat(2)\fR and \fBstat(2)\fR are only updated
when the file is closed.
.PP
Files owned by the object ID 0 (zero) are assumed to belong to the user
and group \fInone\fR.
.PP
No attempt to support broadcast messages has been made.
.PP
No attempt to support printers has been made, however a BSD print server
is a common part of most Netware installations.
.PP
No attempt to support timeouts, retries and wait packets has been made,
it is believed these are relevant only to NCP/IPX implementations.
.SH EXAMPLE
.EX
term% ncpfs -v -k 'user=steve server=fs2' fs2
fs2 steve V5.0 +1sec 144users 65535mtu
term%
.EE
.SH DIAGNOSTICS
If a user is able to access a given server via other Operating Systems,
but \fIncpfs\fR reports a fatal error of the form:
.PP
.EX
\fIserver\fR:\fIuser\fR unknown username
.EE
.PP
The user does not have bindery access to the server,
but only inherited rights through Novell Directory Services
(NDS), this mode of access is not supported in \fIncpfs\fR.
.PP
On startup \fIncpfs\fR may reoprt the warning message:
.PP
.EX
password expiration imminent
.EE
.PP
This indicates the users password has expired, and is currently working but
only within its limited "grace" period. The password should be changed ASAP.
.SH BUGS
\fINcpfs\fR could compensate for the time difference between the Netware
server and the local plan9 client, however it has not yet been proved
that this is nescesssary.
.PP
The Long namespace Netware Loadable Module (NLM) is assumed to be loaded on
the server which is generally the case. \fIncpfs\fR has not been tested
on servers without the this NLM loaded.
.PP
File paths are limited by the size of an NCP packet;
Renaming files requires two paths and is thus further restricted. As \fIncpfs\fR
attempts to use the maximum packet size the server will support no problems have
yet been seen.
.PP
A better (more complete) mapping of Plan9 to Netware permissions may be possible,
see the Netware NFS server documentation.
.SH "SEE ALSO"
.IR srv (4)
.SH AUTHOR
Written by Steve Simon.
.br
Thanks to Petr Vandrovec, author of the Linux ncpfs package, for his help with
the less well documented parts of the NCP protocol.
|