NCPFS(4) NCPFS(4)
NAME
ncpfs - Network Control Protocol client
SYNOPSIS
aux/ncpfs [ -Dd ] [ -s srvname ] [ -m mntpnt ] [ -k keyparam
] host
DESCRIPTION
ncpfs translates between the Novell Network Control Protocol
(NCP) and 9P, allowing 9P clients to mount file systems pub-
lished by Netware servers.
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 informa-
tion.
The options are:
-D print all 9P messages.
-d print all NCP packets.
-k keyparam
lists extra parameters to be sent to factotum 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.
-m mntpnt
set the mntpnt for the remote filesystem; the default
is /n/
-s srvname
post the service as /srv/srvname; the default is /srv/
VIRTUAL FILES
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.
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.
Whoami
Gives miscellaneous info on the currently connected
users account.
NCPFS(4) NCPFS(4)
Groups
Lists the members of each user group. The entries con-
sist of group name, group id, and a comma seperated
list of usernames.
Users
Lists user accounts giving the user name, user ID, Real
name, telephone number, department, and geographic
location.
Printers
Gives the print queues known by the server.
Servers
Lists the other Netware servers known by this server.
Volumes
Enumerates the free and total space (in MBytes), and
free and total directory slots for each volume.
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.
LIMITATIONS
No support for IPX is attempted, all NCP connections are
made using Native IP (NCP over a TCP/IP link).
No support for IPX signatures is attempted. If the security
policy of the server requires these then ncpfs will not work
as it stands.
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.
All group names reported are one of the groups the owner of
the file or directory belongs to. The group selection algo-
rithm tries to find a meaningful group name, enshuing every-
one and none if possible.
File permissions are almost meaningless. Files are always
either 0666 or 0444 mode depending on the Netare ReadOnly
attribute. Directories are either 0777 or 0555 mode depend-
ing upon their inherited rights mask (any restriction on the
directories rights simply selects 0555 mode).
Netware permissions are relaxed a little, the ReadOnly
attribute is removed when during file or directory, rename
or delete operations. This is necessary for CVS.
NCPFS(4) NCPFS(4)
File and directory last access times have only day resolu-
tion and appear as midnight (IE. the start) of the day in
question; Modification times appear as expected.
No attempt has been made at support for 64 bit files. These
are only supported in a patched version of Netware 6.0.
Changing the owner or group via wstat(2) is not possible,
and only a single readonly file mode is supported:
flags = (r->d.mode & 0222)? 0: FAreadonly
Files are always opened as sharable, This is not the case
for files held open by other operating systems.
File sizes returned by dirstat(2) and stat(2) are only
updated when the file is closed.
Files owned by the object ID 0 (zero) are assumed to belong
to the user and group none.
No attempt to support broadcast messages has been made.
No attempt to support printers has been made, however a BSD
print server is a common part of most Netware installations.
No attempt to support timeouts, retries and wait packets has
been made, it is believed these are relevant only to NCP/IPX
implementations.
EXAMPLE
term% ncpfs -v -k 'user=steve server=fs2' fs2
fs2 steve V5.0 +1sec 144users 65535mtu
term%
DIAGNOSTICS
If a user is able to access a given server via other Operat-
ing Systems, but ncpfs reports a fatal error of the form:
server:user unknown username
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 ncpfs.
On startup ncpfs may reoprt the warning message:
password expiration imminent
This indicates the users password has expired, and is cur-
rently working but only within its limited "grace" period.
The password should be changed ASAP.
NCPFS(4) NCPFS(4)
BUGS
Ncpfs 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.
The Long namespace Netware Loadable Module (NLM) is assumed
to be loaded on the server which is generally the case.
ncpfs has not been tested on servers without the this NLM
loaded.
File paths are limited by the size of an NCP packet; Renam-
ing files requires two paths and is thus further restricted.
As ncpfs attempts to use the maximum packet size the server
will support no problems have yet been seen.
A better (more complete) mapping of Plan9 to Netware permis-
sions may be possible, see the Netware NFS server documenta-
tion.
SEE ALSO
srv(4)
AUTHOR
Written by Steve Simon.
Thanks to Petr Vandrovec, author of the Linux ncpfs package,
for his help with the less well documented parts of the NCP
protocol.