Troubleshooting

How to set FileWave Server components to debug mode

For troubleshooting purposes, it may be useful to set the FileWave server to debug mode. When troubleshooting issues with the FileWave server, booster, LDAP collection and syncing, as well as Software Update catalog issues, debug logging will give you extra information that may help you or the FileWave support team resolve a technical problem. 

Step-by-step guide

In order to set debug logging for fwxserver.log, fwldap.log, fwsu.log:

  1. Linux/Mac server - navigate to /usr/local/etc/server.lvl
  2. Using a simple "echo 99 > /usr/local/etc/server.lvl" on Mac / Linux, the debug log level can be set. Keep in mind that initially, the file "server.lvl" may be an empty file if you have not set the debug level in the past. 

If you do not see the server.lvl file at the location on your server you are able to create the file on the server in a text editor or with "echo 99 > /usr/local/etc/server.lvl" on macOS and Linux servers.

If you are troubleshooting issues with the FileWave server and need the fwxserver.log to be in debug mode, no restart is required after setting the level in the server.lvl file. If you are troubleshooting an issue with any other process (LDAP, Software update, Booster issues), then you will need to restart the FileWave server services / processes. 

Please remember to set the debug log level back to the Standard log level once you have completed troubleshooting the issue at hand.

The logging levels are as follows:

10 : Standard Log Level
99 : Debug Log Level
101: Trace Log Level

In order to set debug logging for the django component (filewave_django.log):

  1. Linux/Mac server - navigate to /usr/local/filewave/django/filewave/
  2. Linux/Mac - edit the settings_custom.py file with the command "vi settings_custom.py" to open the file with the vi editor. 
  3. Remove the "#" just before "DEBUG = True"
  4. Save the file 
  5. Restart apache with the command "fwcontrol apache restart"

Please remember to set the debug log level back to the normal by adding the hash (#) back to the "DEBUG = True" line. Restart apache again once you have completed troubleshooting the issue at hand.

fwxserver folder relocation in FileWave Server 13.1.4+ on macOS and Linux Platforms

Does this affect my installation? 

If you are on FileWave Server 13.1.4 or higher this article will not apply to you.

To determine whether action is required from you immediately prior to the upgrade to FileWave 13.1.4, please run the following command as root on your FileWave server : 

if [ ! -z "`mount | grep /fwxserver`" ]; then echo 'Action required' ; else echo 'You are good to go' ; fi

If this command returns "Action required" on your server, you will have to read on and take action right before upgrading to 13.1.4 - if "You are good to go" is returned, please make sure your Backup Script is up to date via Automated Backup, and you're well prepared to continue with the usual upgrade instructions

Background Information

On macOS and Linux, FileWave Server up until Version 13.1.3 stores both DB ( postgres Database ) and Data Folder ( FileSet Repository ) in the /fwxserver folder on the root of the filesystem. 

Architectural changes in macOS Catalina make it necessary to move this data to /usr/local/filewave/fwxserver , since the root filesystem will be read-only from macOS Catalina onwards. 

For most installations, the only change that is required is an update to the newest version of the Backup Script to make sure that the new locations are taken into account.  Please refer to Automated Backup for an up to date download. 

FileWave fwxserver 13.1.4 contains an automatic routine to do this migration for you, and if you have not relocated your Data Folder or /fwxserver folder to another volume, this will work without admin intervention. 

If you have followed the following article:  Store the FileWave Server/Booster Data on a Separate Volume , meaning you have moved the Data Folder to another Volume, and then created a Symlink to your alternative Datastore to /fwxserver/Data Folder, all that is going to happen is that the symlink itself is going to be moved, and none of the data is moved. No admin intervention is necessary. 

Manual Intervention in case of Mount Point Utilization

Please note that FileWave support is happy to assist you with this should you feel uncomfortable doing this yourself. Please contact us using https://help.filewave.com in this case, or by calling us. 

Please note that the changes outlined below will make your FileWave Server inoperable with any version below FileWave 13.1.4. If you do not have the FileWave 13.1.4 installer ready to go, please come back to this article when you do.
Please also note that during the time you implement these changes, your FileWave Server services will be offline. The total duration of the change should be less than 10 minutes - after which you can start the usual upgrade procedures.

Step 1 - Server shutdown

sudo fwcontrol server stop

Step 2 - Determining mountpoint(s) related to /fwxserver, and unmounting them 

mount | grep /fwxserver|sed -e 's/.*on \(.*\) type.*/\1/'|xargs -t umount

Step 3 - Moving the mountpoints to their new location in /usr/local/filewave/fwxserver

Linux: Open the /etc/fstab file in a text editor of your choice.  

For each of the lines in the output of Step 2, replace - in the second column - /fwxserver with /usr/local/filewave/fwxserver, i.e.  :

/dev/mapper/centos-fwxserver /fwxserver                       ext4    defaults        1 1

Would Become :

/dev/mapper/centos-fwxserver /usr/local/filewave/fwxserver                       ext4    defaults        1 1
macOS : run 'sudo vifs'

For each of the lines in the output of Step 2, replace - in the second column - /fwxserver with /usr/local/filewave/fwxserver, i.e.  :

UUID=DF000C7E-AE0C-3B15-B730-DFD2EF15CB91 /fwxserver apfs   rw	1	0

would become : 

UUID=DF000C7E-AE0C-3B15-B730-DFD2EF15CB91 /usr/local/filewave/fwxserver apfs   rw	1	0

Step 4 - create the mountpoint, remount the volumes, and verify things are where they should be 

for each of the lines modified, remount the volumes by running "mount", and appending the new path for the mount, for instance:

mkdir /usr/local/filewave/fwxserver
mount /usr/local/filewave/fwxserver

Please verify the presence of your data by running : 

ls -la /usr/local/filewave/fwxserver

and checking if your DB and "Data Folder" folders show. 

Step 5 - You're clear to run the upgrade! 

Please don't attempt to start your server until the upgrade; FileWave Versions lower than 13.1.4 will not be able to run in this state . 

You're now well prepared to continue with the usual upgrade instructions.

FileWave Server should not have IPv6 enabled

What

Enabling IPv6 on FileWave Server, Boosters, or IVS could lead to unexpected networking issues. IPv6 is a complex networking protocol that, while supported on macOS and Linux operating systems, is not optimized for use with FileWave. Therefore, it's recommended to use IPv4 for more stable and predictable behavior.

When/Why

This information is particularly important for organizations looking to avoid networking issues related to the use of IPv6 on the FileWave Server, Boosters, and IVS. While FileWave clients can function correctly with IPv6, best practice dictates that IPv6 should be disabled on the server components to ensure optimal performance and stability.

How

For macOS

To disable IPv6 on macOS, you can execute the following commands in the Terminal:

# Disable IPv6 for a specific network interface (e.g., "en0")
networksetup -setv6off en0

For Linux

Note that on FileWave 15.5.0 and higher this is already taken care of in the Appliance images but any older images or custom Debian installs should do the below steps.

On Linux systems, you can disable IPv6 using the following steps:

  1. Edit the /etc/sysctl.conf file:
sudo nano /etc/sysctl.conf
  1. Add the following lines to the file:
# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1
  1. Save and close the file.

  2. Reload the sysctl settings:

sudo sysctl -p

Verify the Configuration

After making these changes, it's advisable to verify that IPv6 has been successfully disabled: