Confluence experiences 'Could not initialize class org.xerial.snappy.Snappy' error
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
Problems involving the 'Could not initialize class org.xerial.snappy.Snappy' error can occur within two different contexts.
First, it might occur while trying to create a new page or edit an existing page. In this case, the following message is displayed within the UI while trying to perform these actions:
As this message is somewhat generic and can occur as a result of different errors, we'll need to take a closer look into the logs to check for occurrences of the org.xerial.snappy.Snappy error.
Second, it's possible for this error to occur while trying to render content within an instance of the Jira Issues macro. In this case, the macro content will include the message jiraissues.unexpected.error.
Diagnosis
Environment
- Confluence 6.x and later
- Confluence is hosted in any of the following operating systems:
- Debian
- CentOS
- Ubuntu
- Red Hat Enterprise Linux
- Alpine Linux
Diagnostic Steps
To further diagnose this issue, we'll need to examine the application and Synchrony logs.
Page Creation/Editing
In cases where this is related to a page editing issue, the atlassian-synchrony.log files will mention some variation of org.xerial.snappy.Snappy. Here are some examples:
:cause "Could not initialize class org.xerial.snappy.Snappy"
java.lang.NoClassDefFoundError: Could not initialize class org.xerial.snappy.Snappy
java.lang.UnsatisfiedLinkError: /tmp/snappy-1.1.0.1-f08e07cc-9064-42a4-9af9-b062417b146f-libsnappyjava.so: /tmp/snappy-1.1.0.1-f08e07cc-9064-42a4-9af9-b062417b146f-libsnappyjava.so: failed to map segment from shared object
clojure.lang.ExceptionInfo: Could not initialize class org.xerial.snappy.Snappy {:type :server-error, :source :server}
Exception org.xerial.snappy.SnappyError: pure-java snappy requires access to java.nio.Buffer raw address field
Jira Issues Macro
In cases where this is related to a Jira Issues macro instance, we'll see messaging like the following within the atlassian-confluence.log files:
2020-12-10 19:55:40,510 ERROR [StreamsCompletionService::thread-10] [xhtml.view.macro.ViewMacroMarshaller] handleMacroExecutionException Error rendering macro: jira
-- url: /plugins/servlet/streams | traceId: a3968fc5d8e9894b | userName: charlie
java.lang.NoClassDefFoundError: Could not initialize class org.xerial.snappy.Snappy
at com.atlassian.confluence.extra.jira.JiraIssuesManager$ByteStreamBasedSupplier.compress(JiraIssuesManager.java:117)
at com.atlassian.confluence.extra.jira.JiraIssuesManager$ByteStreamBasedSupplier.<init>(JiraIssuesManager.java:107)
Additional Diagnosis
Looking further, if the /tmp
partition is mounted on the server, we see that it's mounted as noexec
. We can check this by running the following command on the server's terminal:
mount | grep /tmp
You should see results similar to the following, which confirms that /tmp
has been mounted as noexec
:
/dev/sda7 on /tmp type ext4 (rw,noexec,nosuid)
Cause
The root cause of this issue lies in the operating system's mount point(s), whereby the /tmp
partition has been mounted as noexec
. Mounting a filesystem as noexec means it does not permit the execution of executable binaries in the mounted filesystem.
Resolution 1
The /tmp
partition needs to be remounted as exec
. Please contact your Linux administrator so they can perform this fix. The command below can also be used to remount the partition and resolve the issue:
mount -o remount,exec /tmp
Or, if you do not allow /tmp
to be mounted with exec permissions, you can add the following argument to the <confluence-home>/synchrony-args.properties
file:
java.io.tmpdir=/path/to/your/own/temp/directory
Please check the following guide on how to use the synchrony-args.properties
file depending on your version. The way to pass JVM arguments to managed Synchrony nodes has changed in versions 7.20 and newer, and differs if you use standalone mode:
Also, make sure that /path/to/your/own/temp/directory
is owned by the operating system user account that runs Confluence.
In either case, please be sure to restart the Synchrony service so that Synchrony picks up this change:
- Log into the admin console > General Configuration > Collaborative Editing
- Click the Restart Synchrony button.
Resolution 2
Alpine Linux distribution by default will not have libc6-compat package installed, which provides the symlinks for libc.so.6 / libm.so.6. Check if the package is installed and if not install it.
apk add libc6-compat
Please note that Alpine Linux is not supported by Atlassian as mentioned in Supported Platforms. We have a feature request for that:
- CONFSERVER-52400Getting issue details... STATUS
Resolution 3 (when this affects the Jira Issues Macro and after checking Resolution 1)
- Shutdown Confluence
- Clear the plugin cache by removing the following directories:
- <confluence-home>/bundled-plugins
- <confluence-home>/plugins-cache
- <confluence-home>/plugins-osgi-cache
- <confluence-home>/plugins-temp
- <confluence-home>/bundled-plugins_language
This will remove the plugin cache files only and will not permanently remove any plugins. These directories will be recreated during the next Confluence startup. However, some third-party plugins may store metadata in these directories, so we recommend creating a temporary backup of the directories.
Resolution 4
- Shutdown Confluence
- Add the following system property:
--add-opens=java.base/java.nio=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED
--add-opens=java.base/sun.nio.cs=ALL-UNNAMED
Notes
This problem may also occur when migrating from Linux to Windows. After the first startup on the new server, the following error can be seen in the atlassian-synchrony.log:
{"synchrony":{"entity":"/Customer-Instance-afa0320d-c0c7-3fcf-973e-38159f4035d0/confluence-17171501","ns":"synchrony.sync.hub","level":"warn","throwable":"java.lang.UnsatisfiedLinkError: /tmp/snappy-1.1.0.1-cc895952-7b1a-4dad-aa7d-c51ee5bf9595-libsnappyjava.so: /tmp/snappy-1.1.0.1-cc895952-7b1a-4dad-aa7d-c51ee5bf9595-libsnappyjava.so: failed to map segment from shared object: Operation not permitted
...
{"synchrony":{"message":"synchrony.http.entity-api [warn] Error in put-entity","entity":"/Synchrony-ec07ec53-37cb-3637-be42-10a55a8b6b18/confluence-3736095","ns":"synchrony.http.entity-api","level":"warn","throwable":"clojure.lang.ExceptionInfo: Could not initialize class org.xerial.snappy.Snappy
As we can see, Synchrony is still looking into /tmp directory for the snappy file. To refresh the directory, we need to pass a new valid path to the synchrony-args.properties file as in the following example and restart Synchrony:
java.io.tmpdir=C:\\Progra~1\\Atlassian\\Confluence\\temp
We need to escape the path as in the example above otherwise it will not be picked up correctly by Synchrony.
This problem will also occur if Confluence is running on the ARM platform. Collaborative Editing doesn’t work and the following error can be seen in the atlassian-synchrony.log:
2020-08-18 06:25:26,728 DEBUG [461:StdOutHandler [/home/ubuntu/tmp/jdk-11.0.8+10-jre/bin/java]] 2020-08-18 06:25:26,727 WARN [async-dispatch-9] [synchrony.sync.hubs] [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=aarch64 {:entity "/Synchrony-fbdf18d7-2caa-31dd-a3da-a74dc81c54ee/confluence-65603", :throwable #error {
2020-08-18 06:25:26,728 DEBUG [461:StdOutHandler [/home/ubuntu/tmp/jdk-11.0.8+10-jre/bin/java]] :cause "[FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=aarch64"
2020-08-18 06:25:26,728 DEBUG [461:StdOutHandler [/home/ubuntu/tmp/jdk-11.0.8+10-jre/bin/java]] :message "[FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Linux and os.arch=aarch64"
You can't run Confluence on SPARC based hardware. You'll need to use x86 hardware or 64bit derivatives of x86 hardware as mentioned in Supported Platforms. We have a feature request to support ARM:
- CONFSERVER-60187Getting issue details... STATUS