This section describes known issues for the iFolder enterprise server, Web Access server, and Web Admin server.
5.1 The OES Common Proxy User Password is Not Always Compliant with the Password Policies
If you have password policies that support non-ASCII passwords or that require passwords to be 4 characters or shorter, or 12 characters or longer, make sure you select the option (the default setting) on the OES proxy install screen.
Selecting this option prevents the password-compliance issues with the proxy user after the installation.
If you are installing, then abort the installation and reinstall OES. In the common proxy page, you must provide a password for the common proxy user that complies with your password policy.
5.2 iFolder Configuration Fails
The auto-generated iFolder specific proxy user password is compliant with the default settings of the password policy. If you modify the proxy user password or the password policy, make sure that they are compliant with each other. otherwise the iFolder configuration fails.
5.3 iFolder Configuration Fails at Random
During the OES2 SP3 server installation, the iFolder server configuration might fail. This is a rare occurrence. If this issue occurs, run yast2 novell-ifolder3 to reconfigure the iFolder server.
5.4 iFolder Cannot Use the Common Proxy in Novell Cluster Services
When you are configuring iFolder in a cluster, iFolder should not use the common proxy user. The service level proxy should be used instead.
5.5 The iFolder Web Admin Alias Name Does Not Support Spaces
You must ensure that the Web Admin alias name specified during iFolder configuration has no space. Otherwise, the Apache restart after iFolder configuration fails.
5.6 The namcd Services Must Be Running While Changing the Proxy User Password by Using Common Proxy Script
If namcd services are down, you cannot change the common proxy user password by using common proxy script. This is because the Apache wwwrun user cannot be retrieved from the eDirectory if the namcd services are down.
5.7 The iFolder Setup Throws an Exception if an LDAP Proxy User Already Exists in Active Directory
The iFolder setup throws an exception when you specify the LDAP proxy user DN in YaST and if the LDAP proxy user is already existing in Active Directory. As a workaround, you must either use a new user's DN or delete the existing user for AD and then use the same DN again.
5.8 Reprovisioning Users From One Server to Another Results in Creation of Duplicate Entries of iFolders for the Reprovisioned User
If you reprovision users from one server to another, duplicate entries of iFolders are sometimes displayed for the reprovisioned user in the Web console and iFolder clients. As a workaround, after you reprovison the users, you must log in to the Web Admin console to verify if duplicate entries of iFolders are displayed for reprovisioned users. If duplicate entries are displayed, you must restart the iFolder server to resolve the issue.
5.9 iFolder Deletion Leaves an Empty Directory on the Server
For every iFolder, a directory with iFolder's unique ID as its name is created on the server. All the iFolder data is stored in this directory. When you delete an iFolder, the content of the directory is deleted. However, the directory itself is not deleted.
5.10 Uploading of Files is Possible Only if the Secondary Administrator Sets the Disk Quota
After you create a secondary administrator and assign a group to the secondary administrator, the secondary administrator must assign a disk quota to the users of the group. Otherwise, the users cannot upload any files by using the Web Access console or the iFolder client. This is applicable only if the Administrator console option was selected for managing the group quota while creating the secondary administrator. However, users can create empty iFolders even if the secondary administrator has not set any disk quota for users.
5.11 The iFolder Configuration through YaST Hangs When Active Directory on Windows 2003 Is Configured as an LDAP Source
When you configure iFolder through YaST, if Active Directory (AD) is given as the ldap source, the iFolder configuration hangs indefinitely. This occurs only for Active Directory configured on Windows 2003. As a workaround for this issue, follow the steps given below:
-
First, you must export the AD server certificate on Windows 2003:
-
Click to launch the Certification Authority application.
-
Select a certification authority, then right-click and select .
-
In the Properties window, click the button.
-
In the certificate window, click the tab and click the button.
-
Click in the Certification Export Wizard window.
-
Select encoded and click .
-
Specify the path and filename of the certificate and click .
-
Click to export the certificate.
-
Finally, copy the exported certificate file to the Linux server, and run the following command from the command terminal:
certmgr -add -c -m Trust win2k3-vin.ifolder.ad_win2k3-vin.crt
NOTE: If iFolder is configured in a cluster environment, this step must be executed for all the nodes.
5.12 iFolder Does Not Support Spaces or Dots in the Admin DN and User Container DN
iFolder does not support spaces or dots in the admin DN and user container DN. If the Admin DN or user container DN has a space or dot in it, iFolder configuration fails. This is applicable for all directory services.
5.13 Delta Sync Is Not Supported for Encrypted iFolders
Modifying any file in an encrypted iFolder performs a full sync to the iFolder server, instead of synchronizing only the changes.