"Error: File Protocol Error Occurred ..." messages when using Storage, Archive Versioning, File Protocols, and Clustering Plug-Ins for iManager.
This document (3417215) is provided subject to the disclaimer at the end of this document.
This is a generic error message. This error means that we could not communicate with the server using any of the following protocols, listed below in the order they are tried.
CIMOM (OpenWBEM Common Information Model Object Manager)
NCP (Novell Core Protocol)
CIFS (Common Internet File System)
In iManager there are three plugins that use this same authentication mechanism.
Archive Versioning (Archive Versioning plugin)
Clusters (Cluster Services Management plugin)
Storage (Storage Management plugin)
IMPORTANT:The storage-related plug-ins share common code in the storagemgmt.npm file. If you use more than one of these plug-ins, you should install, update, or remove them all at the same time to make sure the common code works for all plug-ins.
NOTE: You need to add to reference the new plugin (Common Storage plugin, storagemgmt.npm).
If the common plugin is not installed, the other three plugins will not work.
The common code is only deleted if the storagemgmt.npm is uninstalled.
If you update the storagemgmt.npm, you may cause any of the other three not to work if they are not updated.
- Make sure they are on iManager 2.5 that ships with OES SP2 or later and the plugins need to end with 20051213 (or later) as see in in iManager | Configure | Module Installation | Installed Novell Plug-in Modules”. Look at Archive Versioning, Cluster Services, and Storage Management.
- Only test with the admin user or admin equivalent.
- Confirm that the IP address that is assigned to the Master IP Address Resource is bound to the server that is running the Master IP Address Resource. Use "ip addr show | grep secondary" and you should see it bound. The Master IP address needs to be the same in the cluster load and unload script, in the attributes of the cluster object in "NCS:Network Address" and "Network Address" with UDP and TCP.
Make sure user is LUM enabled
- use "id USER” where USER is the user they are using to authenticate. Compare this UID and GID with the LUM information in eDirectory. If this step does not work, check to see if namcd is running.
- "/etc/init.d/namcd status"
- If it is not running, start it with "/etc/init.d/namcd start"
- If it is dead, restart it with "/etc/init.d/namcd restart"
- In some cases it may be nessasary to point lum to a diffrent ldap server.
In iManager go to eDirectory Administration | Modify object | Select your USER. In the pull down menu select "Linux Profile Page” compare this UID and GID to the "id” output above. If they are the same then LUM is working if not then fix LUM for this user.
- verify that the user id is unique (admin.novell and admin.users.novell cannot both be lum enabled - that would create more than one 'admin' user in linux with two different uid's.)
to make sure OpenWBEM is a LUM enabled service. Default OES
installation the service is enabled. You may check
the /etc/sysconfig/novell/lum1 file for the following.
You can also check the Unix Workstation object in iManager. Using iManager select "Linux User Management" and Modify Unix Workstation Object. Select the Unix Workstation object for the server. In the Linux Profile you should see which LUM Enabled Services are enabled. Make sure "openwbem" shows up in this list. Also make sure "admingroup" shows up in the Groups section as well. By default, this service is enabled when installing OES.
If it's not configured you should run 'YAST2 novell-lum' and LUM-enable the OpenWBEM service.
With debug options enabled for openwbem you will see in the output log that the user root will fail to authenticate where the user logged into iManager is the user it should be using.
Example output from /var/log/messages with debug enabled for openwbem.
openwbem: HTTPServer::authenticate: processing OWLocal
openwbem: HTTPServer::authenticate: authentication failed for: root
the "Network" attributes on the cluster container object. First check
"NCS:Network Address" attribute and make sure the hex translates into
the IP Address for the Master IP Resource. Next, check the "Network
Address" attribute which has the TCP and UDP port 524 addresses for the
Master IP Resource address as well. These addresses should match the
"NCS:Network" address. If these addresses differ, manually change them
to match. This could be the case if the IP address was ever changed on
Symptom: iManager Storage plugin is working but the iManager Cluster Options or Cluster Manager does NOT work. When you select the cluster object, the screen appears to hang and takes 2-3 minutes to time out. It doesn't show the typical file protocol error or any other error very useful.
- Check the /var/log/messages file for "ldap_initconn" you may find several lines similar to the following:
Mar 17 14:18:16 SERVER1 /usr/sbin/namcd: ldap_initconn: LDAP bind failed (error = ), trying to connect to alternative LDAP server"
If so then there is a LUM problem. Follow the information in
TID 3401691 - namcd cannot connect to LDAP server
This error can also occur (with LUM working properly) if the server is trying to connect to eDirectory/ldap over port 636, but is unable to do so. Check the /etc/nam.conf for the "type-of-authentication=" and make sure this is set to 2 (and not 1). Option 1 is for port 389 and option 2 is for port 636 (or secure ldap). A workaround, or another possible solution for this, is to make sure that "Require TLS for Simple Binds with Password" is not checked under the ldap group object for the server you are trying to authenticate into.
- Test each of the three plugins (Archive Versioning, Clusters, Storage) to see if you get the "File Protocol Error ...” If you get the error on only one of the plugins then you know that it is specific to that plugin, and the authentication protocols are fine (CIMOM, CIFS, NCP). Then troubleshoot using the following steps
Check /etc/opt/novell/ncs/clstrlib.conf file on all cluster nodes. If changes are made then the server needs to be rebooted for the changes to take effect.
S'ldaps://184.108.40.206:636'This IP address needs to point to a Master or R/W replica that can respond via LDAP, by default it chooses to its own IP address.
S'YmFzZTY0bm92ZWxs\n'This is the encrypted password of the person that installed clustering. If this password has changed then put it inside the single quotes in clear text and it will become encrypted after reboot.
S'cn=wss-linux-cluster,o=novell'Confirm that the cluster object has not been moved and this is correct.
Storage and Clustering
Turn on VFS (Virtual File System) logging in NSS. Use 'screen' to gather the output of a terminal session.
On the server that you browse to in iManager (when using the storage plugin). Start the 'screen' program with "screen -L” (the prompt will move to the top of the screen. This means the 'screen' session is active)
Enable vfs logging with "/vfs” (this will just give you a blank prompt). Leave this terminal open. (The vfs messages are also sent to /var/log/messages)
- Reproduce the "File Protocol Error” using the storage plugin. You should see XML scrolling in the nsscon window.
- If you see XML comming out when you duplicate the file protocol error then the problem is with the application (clustering, NSS, etc.).
- If you do not see XML then it is not getting through the communication protocol (which is usually going through the CIMOM, so troubleshoot the CIMOM piece)
Turn off vfs logging with"/novfs”
exit NSSCON with "exit”
exit screen logging with "exit”
get the /root/screenlog.0 file that holds the debug information.
Use the following steps, only if all three plugins show the error. We will handle each protocol individually. This should be done on the server that is holding the"Master_IP_Address_Resource” as seen by the "cluster resources” command (all iManager clustering is done via the server holding the Master_IP_Address_Resource). You will only see a Master_IP_Address_Resource on a system that is running clustering.
Check to see that CIMOM is running with "rcowcimomd status” if it is then restart it with "rcowcimomd restart” if it is not running the start it with "rcowcimomd start”
Test again in iManager if it fails then we need to put both iManager and CIMOM in debug mode and reproduce the error and send engineering the log files.
Place iManager into debug mode.
Click the Configure icon in iManager (Looks like a person at a desk)
Select iManager Server | Configure iManager
Choose the Logging Events tab
Change the logging level to "Errors, Warnings and Debug Information messages"
Under Logging Output choose clear.
Place owcimomd in debug mode.
Then start the process manually, placing it into debug mode and piping the log to a file with "/usr/sbin/owcimomd -d > /tmp/owcimomd.log 2>&1” you will be moved to the next line but not get a prompt, just leave this terminal open.
Reproduce the "File Protocol Error”.
CTRL-C the owcimomd process
Have the customer send us /tmp/owcimomd.log and /var/opt/novell/iManager/nps/WEB-INF/logs/debug.html (from the server running iManager as seen in the URL)
Restart CIMOM with "rcowcimomd start”
Go back into iManager and place the Logging Level back to "Error", and save it.
NCP starts with edirectory. Make sure it is running with "rcndsd status”
Ensure that ncp2nss is running with "ps aux | grep ncp2nss”
CIFS (NetWare only)
- Check to see that the CIMOM is receiving connections from iManager.
You'll see something like this:
 Received connection on 220.127.116.11:5989 from 18.104.22.168:58376
- If you don't see this, iManager is not connecting to the CIMOM. Check IP addresses, firewalls, other usual suspects. If you are receiving connections, look for authentication failures, or other instances of the word "fail" or "Fail" that may be related to the NSS admin volume provider. "
- If you are on a 64 bit server then you could possibly not have the owcimomd providers that you need.
- The fix is to creae a symbolic link "ln -s /opt/novell/lib64/openwbem/c++providers/libNovell_NSS_AdminSession.so
If you see the following in the owcimod debug log then you have this problem.
 XMLExecute::processSimpleReq caught CIM exception:
Search for "CIMOM” or "NSS”. Then look for specific errors when it tries to login.
Trying CIM/XML protocol
11/10/06 [11:26:37.077] VirtualFile...........-1 Exception caught trying CIMOM protocol: 30602
11/10/06 [11:26:37.078] VirtualFile...........-1 Trying NCP protocol
11/10/06 [11:26:37.080] VirtualFile...........-1 Exception caught trying NCP protocol: 30602
The 30602 is an access denied exception that the iManager plugin throws
Below is a list of error messages and their meanings
/* ARK File errors */
/* NCS and BCC File errors */
/* authentication errors */
/* iManager errors */
NOTE: When we attempt to talk to the admin volume from iManager, we get the credentials (username, password), IP address from iManager. So you can also encounter errors when trying to get this information from iManager (30650 – 30659). If we successfully get this information from iManager, then we try to authenticate to the admin volume using the protocols (CIMOM, NCP and CIFS). CIMOM exceptions are 30600 – 30605.
All protocols can throw the read, write, open, position, seek and close errors.
- Confirm that the cimom is running with "modules owcimomd". It should come bac with a few lines.
- If the owcimomd is not running type "openwbem.ncf" and then recheck if owcimomd is running.
- Determine if the same user is starting the comom? Check the sys:\system\cimom\etc\openwbem\openwbem.conf file.
- owcimomd.allowed_users = * or what ever user has rights to the cimom.
- http_server.http_port = -1
- http_server.https_port = 5989. It might have a ; at the start of the line meaning that is commented out.
- http_server.max_connections = 30. It might have a ; at the start of the line meaning that is commented out.
- Try changing the following variable in the openwbem.conf file "owcimomd.allow_anonymous = true" and restart openwbem and test again. This allows a client to bypass secure authentication. If this works and /or you've changed or updated your server certificates using pkidiag recently, follow the directions in step 6.
- Use the bash console in NetWare to recreate the *.pem certificate file that openwbem uses. Type "bash" at the console to open a new bash shell. This should open a screen and be at a "#" prompt in the current working directory of "/usr/home". Change into the following directory. "cd /system/cimom/etc/openwbem/ " In this directory is a bash script which can be used to recreate the "hostkey+cert.pem" certificate file. From this directory inside the bash shell type "./owgencert --force". You can do a "dir" listing which should show a new file date on the "hostkey+cert.pem" certificate file.
log.main.level = DEBUG
This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:3417215
- Creation Date:07-MAR-08
- Modified Date:04-FEB-13
- NovellOpen Enterprise Server
Did this document solve your problem? Provide Feedback