Older Ifolder 1.x and 2.x newest tips will be at the bottom of the page.
These instructions apply to iFolder 3.8 or 3.9, specifically the client. If you are getting Unhandled Exception Errors when clicking on various buttons in the client (login, for sure), this should help. My problem started when trying to move from iFolder 3.8 on OES2 to iFolder 3.9 on OES11. The client versions involved probably don't matter so much, but I had issues with the latest (3.9.2) on OES11 (March 2015 patches) as well as the version served up by my OES2 server (all patches to March 2015). The problem happened when I tried to add another iFolder server in the Accounts menu. Once I pointed to a new server, my clients had all sorts of crashes. All clients were running on Windows 7 64-bit with latest patches. The problem seems to occur because of conflicting information of some sort in the local simias files stored in the user's home directory. On Windows, that is in a hidden folder under [user]/AppData/Local/Simias.
These instructions apply to iFolder 1.0, installed on NetWare 5.1. In the example below, I moved files from a beta2 iFolder server on NetWare 5.1 to a version 1.0 iFolder server on another NetWare 5.1 server. The procedure for iFolder 2.x will be similar.
Note: I experienced an error connecting with my Win2k laptop (involving the RecBinVwr.exe file) in the above process. This error involved an automatic update process controlled by a batch file in the iFolder document root directory, Update subdirectory. Some investigation revealed that any .exe file trying to copy over gave me the error. It looked like a permissions issue with Win2K, but I don't really know. The non-.exe files copied over without error. Since I was running the beta2 iFolder client on my laptop, and iFolder 1.0 on the server, I thought it might be related to some beta bug, so I manually deleted the iFolder client from my laptop, connected to the iFolder server address in Netscape, downloaded the client file manually, and reinstalled. This worked without a problem.
Q. How do I set up iFolder, which requires the Apache web server, on a server already running Netscape Enterprise Server?
A. You can run both servers at the same time as long as each listens on a different IP address. If installing Apache on a NetWare server already running NES, follow this procedure:
Q. How do I install iFolder on a NetWare server running BorderManager that has SSL Proxy Authentication configured? I get an error trying to run Apache about not being able to
use port 443.
A. BorderManager SSL Proxy Authentication listens on port 443 by default. However, that default can be changed. In NWADMN32, BorderManager Setup, specify a different port number, such as 444,
and click on OK to save the changes. If that doesn't quickly change the SSL listening port, you can unload/reload PROXY.NLM. Apache should now start without the 443 error.
Q. I set up iFolder on my NetWare 5.1 server, and it worked for a while. But suddenly I could not log in, getting password errors in the client. Trying to log in as the
administrator account in the iFolder server admin menu also failed with a 'Login Failure' message. Is there anything I can try to get this working again?
A. Try UNLOAD NLDAP and then LOAD NLDAP on the NetWare 5.1 server being used as the LDAP server. See next tip as well.
Q. I've set up iFolder and followed all the suggestions for Clear Text LDAP authentication, trustees, LDAP proxy users, etc, but I can never get logged in. The login at the
client as well as the admin server web page gives me login failure messages. What am I doing wrong?
A. Be sure you have the correct starting context set in the httpd_additions_nw.conf file. For instance, if you have an Organzation unit called ABC, and are trying to log in as the admin user,
be sure the LdapLoginDnContext is calling out "*o=ABC" and not "*ou=ABC". Easy to overlook an ou for an o... This may not be the correct syntax for your version of iFolder, but there is another way
to set this up. Using the Admin login to the web interface for iFolder, go into the LDAP configuration options, and there will be an option "Search subcontainers". Let iFolder make the settings for
you! (This is for iFolder version 1.x).
Addendum, Feb. 4, 2003: Might apply even if login worked at one time! The issue could be related to access rights. See both of these TID's, and go through the steps to reassign rights to
Public in the first one:
Q. I think something is going wrong with the LDAP lookups to my NetWare server, but I just can't see what it is. How can I tell what the iFolder server is asking LDAP, and what,
if any, LDAP errors are occuring?
A. You need to get familiar with DSTRACE commands for LDAP. See this TID:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10062292.htm
Q. I'd like to access my iFolder files through a BorderManager reverse proxy configuration. The iFolder client works fine, but I can't log in with the web-based client. What can
I do to make this work, with iFolder 1.0?
A. The problem is in the HTML coding of the main iFolder page for the login link. It points to the internal IP address of the server instead of the public IP address of the reverse proxy.
Short of modifying the iFolder main web page (see below), you can use the simple workaround of manually typing in the URL with the public IP address substituted for the private IP address. If you
hold your cursor over the Login link, you should see the URL that is to be used by the browser. (http://<private IP address>/applet/java.htm. Simply type in https://<public IP
address>/applet/java.htm, and you should be able to log in and access your files. You will need to have two reverse proxies set up - one for port 80 and another for port 443. The same technique
should work for static NAT. For static NAT, and for reverse proxy on a secondary IP address, you will of course need to allow TCP destination port 80 and 443 in, and the responses back out as
well.
If you want to modify the login link, you can do it quite easily! All you need to do is to edit the ifolder_nav.html file in the \Apache\iFolder\DocumentRoot\html directory. You can even download my version and make some slight changes. In my version, I have a link for Login pointing to an internal address (192.168.10.247), and a link for Internet Login
pointing to my reverse proxy public IP address (4.3.2.247). All you should need to do is to edit the file (Notepad works) to replace the internal and external IP addresses with your own, and replace
your old file with the new version. After that, stopifolder and startifolder at the server.
Q. I can't get my Admin account to log in to the Admin web page to adminster the server. What might be wrong?
A. Aside from the earlier tips, Jason Williams, a forum user, reports that the iFolder 1.0 web page does not pass certain characters in a password:
"It won't pass certain characters in your password through correctly. For instance the exclamation mark ! won't be passed correctly
E.g. Admin with a password of wally! will be passed to the LDAP server by the web page as Admin with a password of wally%21 which fails.
So change your password to wally321 and it works."
Q. I want my local iFolder files to be stored somewhere else than the default My Documents directory on the C drive. How do I do that?
A. From Patrick Brown in the Novell Public Forums, comes this tip, for Windows 2000. iFolder creates it's path in My Documents. The trick here is to move My Documents somewhere else.
Q. I had iFolder client 1.0 working just fine. I upgraded to iFolder Client 1.01 / 1.02, and now my iFolder client doesn't work if a proxy is configured in Internet Explorer.
What can I do to get iFolder working again without disabling Internet Explorer proxy settings?
A. From Mike Mortensen in the Novell Public Forums, comes this tip: "Copy the NIFCLNT.DLL from the 1.0 version over the top and you can use the proxy again." You can get the 1.0 version HERE, and copy it into C:\Program Files\Novell\iFolder.
Note: Doesn't work with Transparent Proxies.
Q. My iFolder client doesn't work when I am using a PPPoE DSL connection. I just get an error "you must connect to the internet" even though I am connected to the Internet. Is
there anything to try?
A. HH in the Novell Public Forums points out this TID, which solved it for him:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10064947.htm
Q. When I run startifolder.ncf, iFolder won't load. I see a lot of 'not multiple' status messages on the console screen. How do I fix this?
A. Add the following as the first line in the STARTIFOLDER.NCF file:
LOAD ADDRESS SPACE = IFOLDER LIBC
Also, be sure NETDB is loaded before trying to start iFolder.
Q. When my Win2k workstation starts up, iFolder crashes, giving me an error for trayapp.exe. What can I do?
A1. See tip #10 above, and try backrevving NIFCLNT.DLL. (Worked for me.)
A2. (Thanks to Paul Gregory for this one) You have created a directory path within the iFolder folder that is too long. Shortening the offending path structure should cure the problem.
(Error: "Trayapp.exe has generated errors and will be closed by Windows"
Q. I can't get iFolder working through Portal. Why is that?
A. From Novell Public Forums user, Kevin Hurni:
I see lots of questions in the iFolder and NPS groups on how to actually configure the stupid AppletLauncher gadget to get it to work with iFolder. Nobody got an answer (I asked too). So I opened an incident with Novell. I'll post the results here to save others $385. First off, the NPS docs are wrong. Anyway, here's what you need to do (the examples I give are ASSUMING that the NPS server is actually a different box than the one running iFolder):
On page 90 of the NPS 1.5 docs you can actually do steps up to 4c. At 4c what they mean is NOT:
"http://ifolder.something.something/applet"
What they REALLY mean (and didn't say) is this:
http://ifolder.something.com
DO NOT enter the /applet path In fact, you ALSO have to COPY the FILES in the sys/apache/iFolder/DocumentRoot/applet directory to the sys:/apache/iFolder/DocumentRoot directory. Apparently NPS needs read access to the directory and that's the only way to do it (without granting file system rights and such). Continue on with the steps
at step 4h:
http://ifolder.something.com (DNS name of whatever your ifolder box is)
at step 4i:
We're good UNTIL passphrase:
The value for passphrase is incorrect. If you input it as shown on page 91, you'll get a funky looking: "%Enter a Passphrase" when the user goes to the page with the gadget on it.
The CORRECT value of the passphrase name is:
%sscustom1 Enter A Passphrase
(note that you basically do NOT enter the last %)
UNFORTUNATELY this does cause the user's passphrase to show on the "box" and in cleartext. (sigh)
Hope this helps others.
--Kevin"
Q. What was your experience in migrating from iFolder 1.03 to iFolder 2.1?
A. I had worried about this for a while before finally taking the plunge. I like iFolder 2.x, but I did find that my upgrade wasn't very automatic. Here are the issues I personally ran
into:
Starting Scenario:
Procedure to get everything working:
Note: iFolder 1.x used a SYS:\APACHE\IFOLDER\SERVER\HTTPD_ADDITIONS_NW.CONF file. iFolder 2.x instead uses HTTPD_IFOLDER_NW.CONF.
Installed iFolder for NetWare on to the NW6SP3 server. The installation detected an existing iFolder installation, so I was hopeful that the upgrade would be fairly automatic. However, since I had
some non-standard settings (custom data directory, multiple context searching), the upgraded iFolder failed to work without additional customization.
First Problem: iFolder failed to start. Turned out that the iFolder installation somehow picked up the server name as the location for the iFolder address, instead of the secondary IP address.
Had to confirm/change the listening address in the iFolder apache files: httpd.conf and httpd_ifolder_nw.conf files. Stopifolder, startifolder. Confirmed that iFolder started up correctly by watching
the logger screen and seeing that it was listening on ports 80 and 443. (Yours could be 51080, 51443, etc.)
A related issue was that the iFolderClient.exe software was pointing to the servername, and not the secondary IP address. I used the FIXUP.NLM program to reset the client software to default to a URL
that resolved to my iFolder secondary IP address.
Second Problem: Could Not Log In To HTTPS://<serverip>/iFolder/Server/Admin. Classic issue, in many ways. I actually have seen two different issues here in two different 1.03-to-2.x
upgrades.
First cause: One upgrade simply didn't work with LDAP using port 636, so I changed the port to use 389. As soon as I did that, LDAP authentication started working. (I used the LDAP
DSTRACE debugging techniques noted in a tip above to see the kinds of LDAP errors that gave me a clue).
Second cause: The second upgrade I did showed LDAP DSTRACE errors that related to an unknown NDS context. I could see "*O=DD" showing up in the DSTRACE. I had to go into the httpd_ifolder.nw.conf
file and change the LdapLoginDnContext from "*O=dd" to "O=dd". I had to make sure that the iFolder administrator account was in the O=DD context, and I also had only one admin user entry. (If you
want to have more than one user ID, note that they should be separated by ; with iFolder 2.0, and the login will be case-sensitive to what you enter in the .CONF file).
Third Problem: User Could Not Sync Data The iFolder client reported that the user was not authorized to sync the data. This is normal. With iFolder 2.0, schema extensions are
added to the user and server objects to tie iFolder properties to individual users. Once you upgrade to iFolder 2.x, you then need to enabled the desired users to make use of iFolder. This is done in
the Users section of the iFolder management page in a browser. (HTTPS://<serverip>/iFolder/Server/Admin). Once you authorize the users, you should then go to the LDAP Servers page,
select the iFolder server, and Upgrade 1.0x users to 2.0.
Fourth Problem: Upgrading Users Did Not Find Any Users to Upgrade My fault. I needed to enable iFolder for the users before doing this AND I needed to make sure that iFolder was
pointing to the correct data directory.
Fifth Problem: iFolder Not Pointing to Data Directory As soon as I authorized myself for iFolder, my client (after I had upgraded the client, by the way) started to sync the data. But
I quickly saw that it was trying to upload all 3GB to the server. It turned out that iFolder was NOT pointing to my VOL1:\IFOLDER directory, but instead had recreated a new SYS:\IFOLDER directory and
was happily re-syncing all my data from scratch. This was another place where the upgrade did not pick up my old settings. I stopped iFolder, and modified the HTTPD_IFOLDER_NW.CONF file to point to
VOL1\IFOLDER again, and restarted iFolder. (Afterwards, I also repeated the upgrade all 1.0x users in the LDAP Servers menu).
Sixth Problem: iFolder Out of Disk Space for User After all of the above, my iFolder client was synching up just fine, when it suddenly reported that it was out of disk space for my user. I
had allotted 4000MB for iFolder, and I had been using 3009MB or so. Suddenly iFolder was reporting that I was using 300900MB. It was obviously miscalculating the data usage and had the decimal point
off. (I upgraded iFolder last night, and was not in the mood to try to troubleshoot this one, so I have no easy answer). TO work around the issue, I simply deleted (moved, actually) my iFolder data
to backup directory after stopping iFolder. Then I restarted iFolder, and am letting my iFolder client move all 3GB of data back up to the server from scratch. (A very slow process - taking about 12
hours at this point). I'd appreciate it if someone knows the answer to this one and can email me - I will post a solution here if it exists.
Bottom line on the upgrade - it was relatively painless, except the 6th problem making me resync my data. I did have to go back into two .CONF files and make some changes to get the iFolder server
listen on the correct IP address, and LDAP to work, and the data directory to point to my location. You may not need to do any of that. I also had to enable users for iFolder access, which anyone
upgrading to iFolder 2.x will have to do. iFolder 2.x added a lot of schema extensions in my tree, which caused me no issues, but my tree was healthy to begin with. (Note: My personal LAN has four
servers with DS 6.17, DS 85.27c, DS 85.30 and DS 10410.99 running). I really like the way iFolder works to start with, and I like the additional iFolder 2.0 features, such as potential for pass
phrase recovery, custom iFolder data directory location, control by user, and additional reporting functions. I plan to also test on Win2k and RedHat 8 when I get the time.
Note: Up to iFolder 2.0, the STARTIFOLDER.NCF file was used to launch iFolder, in a protected memory space. With 2.1, iFolder has been integrated into the main Apache startup, and won't load into a
separate space anymore. (There is a TID on changing things back to the old way).
(See the next tip as well for a fix that may not involve a complete reinstall).
Q. I installed eDirectory 8.7, and iFolder 2.0 quit working. What might be the problem, and how can I reinstall iFolder 2.0?
A. This only covers one problem I have seen, but the details might be useful to someone needing to reinstall iFolder 2.x as a last resort to fix various issues:
Symptoms:
1. iFolder client would not work - 'connection broken'
2. iFolder admin login to iFolder 2 management console worked, but when looking at the LDAP user object, no contexts were displayed. Could delete the object, but never could create another one.
3. Could never select or add an iFolder user, due to the lack of server contexts shown for the LDAP user object.
4. DSTRACE of LDAP information showed -669 (invalid password) errors when iFolder started up, relating to the iFolder_ServerAgent object.
5. Configuration files for Apache and iFolder seemed fine.
6. Installed eDir 8704 patch, and extended the schema, and enabled anonymous binds OK, but this did not help the problems noted above.
The two most pressing issues were the failure for the iFolder_ServerAgent to log in (I have next to no information on the purpose and use of that object), and the inability to get a user LDAP object
to display any contexts so that users could be located and enabled for LDAP. Because I could not solve these issues, I decided that it would be best to reinstall iFolder 2.0 and let it recreate the
objects.
However, a simple reinstall of iFolder 2.0 did not fix anything. I tried renaming the existing iFolder objects (iFolder_ServerAgent, iFolder_Settings, iFolder_ldap01, iFolder_server), but the
reinstall did NOT recreate those objects.
Those objects are supposed to be created / updated after you install iFolder 2.x, and log in to the iFolder admin management console (in a browser) the first time.
I then found useful information in the Novell Public Forums, posted by Don Horsfall on Sept. 30, 2002. Here is the procedure he (and I) used to force iFolder to reinstall the schema additions and
necessary iFolder objects into NDS. First, install or reinstall the iFolder 2.x files.
1. Stop iFolder. (Stopifolder command for 2.0 or earlier, NVXADMDN for iFolder 2.1)
2. iFolder will not recreate necessary iFolder objects in NDS if it senses that the schema has already been extended and certain objects are seen. These objects need to be deleted (or renamed) first.
The objects which need to be deleted/renamesd are:
-iFolder_ServerAgent
-iFolder_ldap01 (could be 02, 03, etc.)
-iFolder_Settings
-iFolder_server01 (could be more)
3. You need to delete as many iFolder schema attributes and classes as you are allowed from the schema. (You will not be able to remove them all). Use ConsoleOne, Tools, Schema Manager to do this.
You want to try to delete 4 Classes (ifolderLDAP, iFolderServer, iFolderSettings, iFolderUser), and 15 Attributes that start with 'iFolder'.
4. Start iFolder again, so that you can log into the web-based management console.
5. Log in to the iFolder Management Console in your browser. At this point, iFolder should senses that the schema has not been extended, and should reinstall schema extensions and recreate the NDS
objects. You can use ConsoleOne to see them.
6. In the iFolder management console, configure iFolder, and stop/restart iFolder as needed.
Q. I installed eDirectory 8.7, and iFolder 2.1 quit working. What might be the problem?
A. The problem may be with the NLDAP.NLM that ships with eDirectory 8.7. It may fail to extend the schema via ldif files. Try rolling back to an older version, such as the version that came
with edir8703. (If that does not work, see the previous tip on reinstalling iFolder). (Thanks to Andy Cox for this tip).
Q. I get a "Class NIDApplet not found" when I try using iFolder 2.1 pro. This has begun after changing the iFolder server IP address. What might be the problem?
A. Mike Ence reported a possible fix in the Novell Public Forums, as follows:
"I'm posting this for the record- I've seen a few posts regarding this, but none were actually helpful, and no viable solution\fix\workaround actually came to light:
After trawling the Net, Novell and Newsgroups ad nauseum, I finally hit upon the idea of trying Novell's iFolder demo website. Unsurprisingly, this worked flawlessly.
The next step was to find out how it differed from the website provided in the iFolder install- there are quite a few differences, but mostly cosmetic.
What I did realise, is that the link to take you to the demo is not on a frames page. On this basis I tried https://<myservername>/ifolder/applet/java.htm. It worked. First time. No hitting ctrl-F5, nothing. So I edited the ifolder_nav.html file, found the 'Login' link, changed the 'target=content2' to 'target=_top' and guess what? No problems.
Seems M$ have a bug of sorts in their implementation of applets within frames pages. Either that, or Novell haven't coded it properly. But I think the former, for the simple reason that IE itself opens without a hitch when it's not in a frames page, and Opera 7 w/java opens it without a hitch even when it is. And yes, IE had Sun's java 1.4.1 installed on the machine in question.
By the way, if you want to keep the original frames page you could using _blank instead of _top to open in a new window. Or if you want it to look somewhat similar to the iFolder demo website, you could try adding a header\footer to the java.htm, as having *just* the applet running is rather bland looking. For pointers on this, one option is to view the source of Novell's own iFolder demo website, or try htmlhelp.com."
If you have upgraded to eDirectory 8.7, or have just installed iFolder on a NetWare 6.5 server, you might see this issue. TID 10092590 has the answer - you need to change an LDAP
Server option as the default value has changed from previous versions of NDS. In ConsoleOne, on the LDAP server object, General tab, check "Return operational attributes when all attributes are
requested".
I've seen this problem a couple of times now, when upgrading to iFolder version 2.1.3. In one case, a client of mine had this happen when he installed NW65SP2. In my case, I was running
iFolder 2.1.0 on NetWare 6.0, and I downloaded iFolder 2.1.3 and upgraded that way. The problem occurred when I updated the client piece. (The server upgrade was fine - no problems there).
My older iFolder clients continued to connect to the server without any problem. But when you connect the client to the server, it also checks for newer versions, and I let it update the client to
version 2.1.3. After I rebooted the PC, to put the new client into place, I could no longer make the connection to the server. I either got a broken sync, or just a 105 error in the iFolder
client.
TID #10094889, "Resolving "Unable to connec to to Server (-105)" after iFolder upgrade" has a partial fix. You need to go into the registry and delete some extra information on the ServerLocation
entry. What that tid doesn't say is HOW the information gets there, nor does it mention that every time you try to log into iFolder, the old information gets put back in!
When you log into the iFolder client, the address you put in the client is not what is used to connect to the server to transfer data. It is only used to log in, at which point it becomes a registry
entry. Then, the string value of that entry is pulled down from the iFolder server configuration. Here is where you can have a problem; a problem that did not exist for me with ver 2.1.0.
In the iFolderServer/Admin management interface, there is a menu entry called Ifolder Servers on the left. If you select that, you should see (at least) an entry like Ifolder_server01
(default). If you select that link, you should have a menu that allows you to set public and private names/addresses, and port numbers. The public address is what is to be used when connecting
from the internet (might be a statically-natted public IP address), while the private address is what is used to connect from inside the firewall (private IP address). You may have a DNS name instead
of an IP address.
The problem is that with iFolder client ver 2.1.3, BOTH of the entries are added into the registry for the string value for the server location, and the entire string value is sent out for DNS name
resolution when the iFolder client tries to connect to the server. The tid tells you to delete the semicolon and everything behind it. Unfortunately, this doesn't work if you have entered both a
public and private address/name in the management configuration.
The fix: Use only ONE entry in the management config, and leave the other entry blank. Then only one entry gets pushed into the registry, and it should work with the ver 2.1.3 client.
Q. I have used iFolder on various PC's, and I usually see that it is a bit slow
to download or upload large amounts of data. But sometimes I've seen it be blindingly fast.
What can cause a huge speed difference?
A. This one took me YEARS to figure out, but it is quite simple. In my usual environment, all
my browsing uses a BorderManager proxy server. When I bypassed proxy for the iFolder URL, the
iFolder speed improved up to 100 times as fast! See the next tip though, it can be tricky to
bypass the proxy.
Q. I have iFolder client installed, and I don't tell it to use the proxy,
but it seems to be using proxy settings anyway. What's wrong?
A. The Windows iFolder client, at least up to version 2.1.3 (latest when I wrote this), has Internet
Explorer dependencies, and it will automatically use the proxy settings in Internet Explorer even
if you do not enter them in the iFolder client config. Basically, the option to use a proxy in the
iFolder client config is there in case you want to use a proxy, and Internet Explorer is not configured
with one. Problem: proxy can slow iFolder down (see tip #21). Solution: Go into the Internet
Explorer proxy conneciton advanced options. Put in the *exact* URL you use in the iFolder client in the
login menu. As an example, I have a url "192.168.10.247:80" - I needed to put that in the bypass proxy
menu, or Internet Explorer would use the proxy anyway. Internet Explorer essentially does a string
match on the URL, and you need to be very precise in what you tell it to bypass. (A wildcard * can
help too).
Q. I have iFolder 2.1.5 installed, and I am trying get iFolder to work on a
non-sys volume. When I try to connect to the server, I get one of the following errors:
Authentication Failed (-23)
Authentication Failed (-25)
Authentication Failed (-40)
Another clue - on the server console, in the Apache screen (and in the error.log file in the
server's iFolder directory), I see the error: Login Encryption Mismatch when I try to sync data
with encryption enabled.
What could be wrong here?
A. This one probably applies to all versions of iFolder, at least up to 2.1.5. In the
iFolder configuration file (in this case, httpd_ifolder_nw.conf), there are lines which call out
the iFolder data volume and directory. Here is the example which led to this tip:
# iFolder Volume \ directory for user files
#
# Edit the iFolderServerRoot
# Edit the iFolderUserRoot (same as iFolderServerRoot, used by iFolderUser module)
# =================================
iFolderServerRoot IFOLDER:\iFolder
iFolderUserRoot IFOLDER:\iFolder
And the problem is simple, but subtle. The directory name you enter is CASE-SENSITIVE. The
directory I had set up was ifolder, and when I renamed it to iFolder, everything started working.