Understanding Filr Administration

The information presented in this article is supplementary to the Filr Documentation that you can find at www.novell.com/documentation. I will discuss various aspects of Filr and include additional information to assist in your day to day administration of the product.

Understanding Storage

Filr acts as an abstraction layer to your existing storage that sits behind the Filr Appliance. Filr can take a volume from an OES or Active Directory system and present it to Filr Clients. Filr can also use what is described as Personal Storage. If Personal Storage is enabled then the data stored is kept on the VASHARE NFS Mount point that is shared between all Cluster Nodes.

For every volume exposed through Filr a Net Folder Server is defined through the Administrative Web Console that exists on port 8443 (default) for each Filr web Appliance.

Filr Net Folders server path can use either the IP Address or DNS Name in a patched 1.01 Filr appliance. Note the Proxy Name and the Proxy Password entries on the Dialog Box. These are used to grant rights to files for processes such as the sharing of data. If a file is shared, the proxy user is utilised to grant access to the file for users that would otherwise have no ability to see the data.

The Net Folder Server will point to the root of the volume in question and child directories on this server can be setup as individual Net Folders. One Net Folder Server can host multiple Net Folders. The user is given a list of Net Folders when accessing data and their initial access is based on both their Filr user and their rights to data in the back-end Servers that host the data.

Figure 1: Configuring a Net Folder Server

The net folder when created is pointed at the net folder Server that must already exist.

The relative path indicates the directory path from the root of the volume where this Net Folder starts. Users must have either Active Directory, or OES Rights to see the data that the Net Folder refers to. The Rights tab allows you to select the security principals that are authorised to see this Net Folder.

Figure 2: Setting up a Net Folder

Home Folders

When you run the LDAP import a user’s home folder is configured within Filr from the home folder attribute read from the directory. This allows the user to have a “special” Net Folder that just refers to their own home directory. This area does not become available until somebody has logged in to the Web Client.

Just In Time Sync (JITS) and other Synchronisation parameters can be set on an individual home folder if required in a similar way to other Net Folders. This is set on the User Properties, Home Folder dialog.


Before Filr can see data from a Net Folder a synchronisation task must be run so that Filr has reference to the file in its own Database. This process is required for data on Net Folders that has not been created by a Filr Client. If content is added to a Net Folder with a Filr client then the content is visible to Filr automatically. If content is added from a mapped drive and a desktop PC for example then a Synchronisation process would have to be run for the data to become visible to Filr.

This task has two modes of operation:

  • Full Synchronisation
  • Just In Time Synchronisation

Full Synchronisation

This process can be triggered from a Net Folder Server or a Net Folder. If a synchronisation task is run from a Net Folder Server then all Net Folders connected from the Server will be synchronised. This process happens immediately when executed from a Net Folder Server. When executed from a Net Folder the process is scheduled in accordance with the following dialog:

Figure 3: Scheduling synchronisation

Note that schedule interval should allow enough time for the sync to complete. Do not set this interval too short.

Just In Time Synchronisation (JITS)

This is triggered based on user activity either through the Web or the Mobile Clients (The Windows Desktop Client does not support JITS). This allows for an unsynchronised Net Folder to be viewed from these clients. When a user accesses a directory on a Net Folder the JITS process is triggered for the files within that directory, but not for any sub-directories.

The JITS processes run in accordance with a time-out that is set globally for all Net Folders. Users Home Folders however do have their own defaults and can be configured differently.

The global setting is configured as shown in figure 4. This setting is found from the Admin Console under Just-In-Time Sync.

Figure 4; Setting JITS

This setting means that JITS will run for 15 seconds and return as much information as it can in that time frame. Display of directory information to the user is delayed in accordance with the time-out value. This value can be any number including 0 and if all files/ directories are not found in the required time then an incomplete list is returned to the user. If 0 is set then the JITS session is fired in the background and the directory listing is returned as soon as possible. A refresh of the directory listing may be required to view any files that have been added to the directory.

Each Net Folder can have further JITS related parameters set but the global timeout still applies (figure 5).

Figure 5: Configuring JITS for a Net folder

JITS can be enabled or disabled on a Net Folder by Net Folder basis. If enabled you can control the Maximum Age for Just In Time Results. This means that if a JITS has run for this directory in the last 30 seconds then the existing information should be re-used and do not run a new JITS session. This value would decide how quickly a file change on a Net Folder from a non-Filr client would become visible to other Filr users.

The ACL age parameter serves a similar function. Since ACL data tends to change less than the files themselves this value can be increased to 86400 seconds (1 Day). This would mean that JITS Acl information would only be updated to cache once per day.

Net Folder Security

Within each Net Folder security can be assigned by the following security principals:

  • Internal Users/Groups
  • External Users
  • Public

Internal Users and groups can refer to objects created both within Vibe and to objects imported to Vibe from LDAP. External Users refer to users who are configured via the external share mechanism by end users and are referred to by their email address.

The groups and users referred to here can be either Filr based or LDAP groups that have been imported from your Directory.

Access to a Net Folder

A user can granted access to a Net Folder from the dialogue above but the final arbiter of security is the file system that the Net Folder points to. The user has to have rights to the back end OES or AD file system directory before any content is seen through Filr. This means that you do not need to reapply your existing access controls to Filr.

Figure 6: Setting Net Folder rights

Understanding the implications of re-share

The access granted to a user can also include the ability to re-share content. If this is selected then the user can share content and the recipient user is allowed to access a file where they have no existing file-system permissions. In this case the NeFolder proxy user is used to access and, if necessary, modify the file.

This means that re-shared content that is modified subsequently by a user that has been granted access will not be logged at the file system level as the last modifier of the file. In this case the host file-system would show the Filr Proxy User as the last modifier.

Once content has been re-shared more than one level then the originator of the original share has no visibility of who the file has been re-shared with. The only way to reference this information is by querying the back-end database.

The File Upload Process

When using either the Desktop Client (Windows/Mac) or the Web Client the file upload process is very similar. All file uploads are staged on the /VASHARE volume in the /filr/temp directory. Within this directory the upload process creates a sub-directories based on the filr user id of the user.

Assuming a clustered environment the upload process follows the steps outlined below.

  • File upload is initiated from a client.
  • File is uploaded over a period of time to the /VASHARE/filr/temp/xx directory where xx is the filr user id of the user. The file is created as a .tmp file with one of two conventions depending on the source of the file upload.
  • If “_” exists in the file name then the source of the upload was either the Windows Desktop Client or the Java Applet from the Web Client.
  • If “.” exists in the file name then the source of the upload was the Web Client using the HTML5 upload option.

Once the file has been uploaded to /VASHARE/filr/temp/xx the file is then moved via NCP/CIFS to the back-end Server holding the Net Folder.

Please note that any tmp files should be cleaned up from the /VASHARE/temp directory even when an upload fails for some reason. However if the move of the file to the back-end file server has started then the incomplete file at the back-end is not cleaned up and will need to be cleaned up manually.

Famt Debug log

The famt debug log is enabled on each Filr Appliance in a cluster. The command for this is:

/opt/novell/filr/bin/famtdconfig -s loglevel 4

This will assist with any issues such as File Upload and Net Folder Synchronisation. Once finished this should be reset to loglevel 1

Default URL for Desktop Client Updates

On initial installation the default URL for desktop updates is not set. This needs to be set to the following value:

Assuming filr.novell.com as the host name, this would change depending on the url for the filr installation.


This dialog box can be accessed from the Web Administration Console on port 8443. From here select Desktop Application on the left hand side of the screen.

Figure 7: Setting the default url for desktop client updates


That concludes this tutorial on the principles and administration of Novell Filr. Adding the extra layer to file management requires a little extra administration but the benefits Filr brings more than compensate.

(This article was first published in Open Horizons Magazine Issue 25, p30-33 April 2014)

Leave a Reply