Accessing NetWare FTP Servers with Web Browsers

Users may experience difficulty when using a web browser such as MS Internet Explorer or Netscape Navigator to navigate a NetWare FTP Server.  These difficulties are often due to a special feature which NetWare FTP servers provide:  Users are automatically able to reach home directories on (or manually navigate to) other NetWare servers in the tree.  This "remote server access" feature is sometimes referred to as an "FTP Gateway" because one NetWare FTP server can dynamically allow users access to their files on any server in the tree.

 

Various typical issues include:

 

Users can access files on the FTP server itself, but cannot access the other servers.

 

Users can reach their home directories, but are not allowed to navigate outside them.

 

Messages regarding lack of response or availability of the server are received when clicking a file link.

 

One possible solution is to edit the browser's URL field to include the name of the file or directory desired.  In other words, specify the needed resource manually instead of relying on the browser's dynamically built links.  So even though the browser is being used, it is not really "browsing".

 

For example:  Using a Text-based FTP client, a user can FTP to one server and then give the command:

 

cd //otherserver/volume/directory

 

The URL for this operation, through a browser, would be (note the use of double slashes in TWO locations):

 

 

Or to access a file it would be:

 

 

Typically, if remote server access is being used, the user will need to enter the above types of syntax each step along the way, instead of clicking on the links automatically built by the browser.  This is not very user friendly, and can be very time consuming and frustrating.

 

NOTE:  In the above examples, depending on the way FTP's user searching is configured, "username" might be a simple username, or might need to be a fully-qualified name, including a leading dot, like:  .user1.sales.corp

 

NOTE:  With most recent browsers, the colon and password can be left out and the browser will prompt for the password.  This allows users to avoid typing in a password that a passerby could see.  Some older versions of MS Internet Explorer will not accept that syntax.

 

The behavior seen when navigating to the "remote servers" can be unpredictable in other ways, as well.  The above discussion includes potential cases where the browser may end up trying to reach the "remote server" directly, as if it was the FTP server.  This typically fails because the "remote server" is simply a NetWare NCP server.  However, imagine a variation where the remote NCP server happens to be an FTP server as well.  This may allow the browser to successfully reach it.  However, failures are still likely, because the browser may have stripped off some of the information (like username) while building the new links.  So clicking the link to make a new FTP connection to the 2nd remote server would attempt to form an anonymous FTP connection.  Success or failure at that point would depend on the anonymous user's rights to that directory, not the rights of the user who was originally authenticated.

 

Additionally, browsers often treat the home directory they first reach as a root directory, and artificially "jail" the users in that location, even if the FTP server itself would not have enforced that type of restriction.  Trying to retype the URL to go outside that path will be problematic, as the browser may, behind the scenes, continue to try to append the original path to the manually typed URL.

 

As the reader is probably realizing, using a web browser as a fully-featured FTP client is not likely to be 100% successful and can be frustrating.  Novell generally recommends a true, dedicated FTP client for those seeking full FTP features.  But if a NetWare FTP Server absolutely must be implemented to allow browser-based access, approaches which may help simplify things are:

 

1.  Be sure the file systems to which your FTP users need access are all on the NetWare FTP server itself.  This will avoid remote server navigation concerns.

 

2.  If remote server access is avoidably needed, then try to create a situation where users will be placed in a home directory on the *one* remote server which contains everything to which they need FTP access.  Hopping from one remote server to another while using a web browser will not be easy or user-friendly.

 

3.  If users need access to common areas (not just their own home directories), override the use of individual home directories and instead set a general FTP home directory.  Set this FTP home directory on the local FTP server, at a "parent" directory of all the areas to which users need access.  That way, even if the browser "jails" them at this level, they can still navigate to all their files.

 

This can be accomplished by using the SYS:ETC\FTPSERV.CFG settings:

IGNORE_HOME_DIR=YES

DEFAULT_USER_HOME=vol:/path

 

As an alternative to the vol:/path syntax shown above, the home directory could be set to the server root.  In other words, the point at which all volumes will be shown in a directory list, so users can navigate to multiple volumes, instead of allowing the browser to jail them in one volume. This would be done with the syntax:  DEFAULT_USER_HOME=/

 

There may be other clever approaches that could help, but those would have to be devised carefully, based on specific needs, and would likely have various limitations which would prevent them from being highly flexible or expandable.  If flexibility, expandability, and access to full FTP features are important, web browsers are poor choices as FTP clients.

Formerly known as TID# 10055592

Formerly known as TID# 2935468