Nextcloud 32 Upgrade Issue: Fixing the Talk App WASM Warning

ByPieter Bakker

The Problem

After upgrading to Nextcloud 32, which automatically upgrades all installed apps including the Talk/Spreed app, the administration panel displays a warning about WASM (WebAssembly) support under the “Background blur” section:

Could not check for WASM loading support. Please check manually if your web server serves `.wasm` files. To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its `trusted_domains` or the `overwrite.cli.url`. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.

This warning appears even when:

  • Apache has the correct AddType application/wasm .wasm directive
  • WASM files are being served with the correct MIME type
  • The Nextcloud container can reach itself through the reverse proxy
  • All connectivity checks pass successfully
  • Background blur feature works correctly

This issue has been reported in the Nextcloud community forum by several users experiencing the same problem after upgrading Talk.

Environment

  • Nextcloud: 32.0.2 (issue occurs during upgrade)
  • Talk/Spreed App: 22.0.4+ (issue introduced in this version)
  • Backend: Apache in Incus container (IP: 10.0.0.50)
  • Reverse Proxy: Nginx (IP: 10.0.0.10)
  • OS: Debian 12

Root Cause

The issue is a bug in the Nextcloud Talk/Spreed app version 22.0.4. The setup check in /var/www/nextcloud/apps/spreed/lib/SetupCheck/BackgroundBlurLoading.php looks for a specific WASM file that no longer exists:

$url = $this->urlGenerator->linkTo('spreed', 'js/tflite.wasm');

However, in Talk version 22.0.4, the background blur feature was refactored to use different WASM files:

  • vision_wasm_internal.wasm
  • vision_wasm_nosimd_internal.wasm
  • olm.wasm

The developers renamed the WASM files during refactoring but forgot to update the health check code, resulting in a false positive warning.

Verification Steps

Before applying the fix, verify that WASM files are actually being served correctly and that the issue is indeed just the health check.

1. Check that WASM files exist

ls -la /var/www/nextcloud/apps/spreed/js/*.wasm

Expected output:

-rw-r--r-- 1 www-data www-data  153573 Nov 20 15:53 olm.wasm
-rw-r--r-- 1 www-data www-data 9574032 Nov 20 15:53 vision_wasm_internal.wasm
-rw-r--r-- 1 www-data www-data 9448638 Nov 20 15:53 vision_wasm_nosimd_internal.wasm

2. Verify MIME type is served correctly

curl -I https://your-nextcloud-domain.com/apps/spreed/js/olm.wasm

Look for:

HTTP/2 200
content-type: application/wasm

3. Test that the missing file indeed returns 404

curl -I https://your-nextcloud-domain.com/apps/spreed/js/tflite.wasm

This should return:

HTTP/2 404

4. Verify PHP can fetch WASM files

From inside the Nextcloud container:

php -r "
\$ch = curl_init('https://your-nextcloud-domain.com/apps/spreed/js/olm.wasm');
curl_setopt(\$ch, CURLOPT_NOBODY, true);
curl_setopt(\$ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt(\$ch, CURLOPT_HEADER, true);
curl_exec(\$ch);
\$info = curl_getinfo(\$ch);
echo 'HTTP Code: ' . \$info['http_code'] . \"\n\";
echo 'Content-Type: ' . \$info['content_type'] . \"\n\";
curl_close(\$ch);
"

Expected output:

HTTP Code: 200
Content-Type: application/wasm

If all these checks pass (existing WASM files work, only tflite.wasm is missing), then WASM is configured correctly and you just need to fix the outdated health check.

The Solution

Create a minimal, valid WASM placeholder file to satisfy the health check. This approach is safer than a symlink because it won’t conflict with future Talk updates that might use tflite.wasm for its intended purpose.

Step 1: Create a minimal valid WASM file

cd /var/www/nextcloud/apps/spreed/js/
# Create a minimal valid WASM module (8 bytes: magic number + version)
printf '\x00\x61\x73\x6d\x01\x00\x00\x00' > tflite.wasm
chown www-data:www-data tflite.wasm
chmod 644 tflite.wasm

This creates the smallest possible valid WASM file:

  • Bytes 0-3: \x00\x61\x73\x6d – WASM magic number (literally “\0asm”)
  • Bytes 4-7: \x01\x00\x00\x00 – WASM version 1

Step 2: Verify the file was created correctly

ls -la tflite.wasm

Should show:

-rw-r--r-- 1 www-data www-data 8 Nov 20 20:15 tflite.wasm

Verify it’s a valid WASM file:

file tflite.wasm

Should return:

tflite.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)

Step 3: Test accessibility

curl -I https://your-nextcloud-domain.com/apps/spreed/js/tflite.wasm

Should now return:

HTTP/2 200
content-type: application/wasm

Step 4: Clear caches and verify

sudo -u www-data php /var/www/nextcloud/occ maintenance:repair

Refresh the admin overview page (Settings → Administration → Overview) with a hard refresh (Ctrl+Shift+R in most browsers). The warning should disappear immediately.

Why This Approach Works

This minimal WASM file satisfies the health check requirements:

  1. Valid WASM format – It’s a legitimate WASM module that browsers and servers recognize
  2. Minimal size – Only 8 bytes, the smallest valid WASM module possible
  3. Correct MIME type – Apache/Nginx serve it as application/wasm
  4. Future-proof – Won’t conflict if Talk updates implement a real tflite.wasm
  5. Safe placeholder – Clearly not a functional module, just satisfies the check

The health check only verifies that:

  • The file is reachable via HTTPS through the public domain
  • It returns HTTP 200 status code
  • The MIME type is correctly set to application/wasm
  • The file is valid WASM format

Our placeholder file satisfies all these requirements without creating dependencies on other files.

Understanding the Misleading Warning Message

The warning message can be quite misleading because it suggests DNS or firewall issues:

“This failure may be the result of a server-side DNS mismatch or outbound firewall rule.”

In reality, if your Nextcloud can connect to itself (which you verified with curl from inside the container), those aren’t the problems. The real issue is simply that the specific file the health check is looking for doesn’t exist – not because of misconfiguration, but because it was renamed in the codebase.

This has led many system administrators down the wrong troubleshooting path, checking DNS configurations, firewall rules, and reverse proxy settings when everything was actually configured correctly.

Why a Placeholder Instead of a Symlink?

You might wonder why we create a placeholder file instead of symlinking to an existing WASM file. Here’s why this approach is superior:

  1. Future-proof – If Talk updates add a real tflite.wasm for TensorFlow Lite functionality, a symlink would conflict and cause issues
  2. Clear intent – An 8-byte placeholder clearly indicates “this is just for the health check”
  3. No dependencies – The health check doesn’t depend on other WASM files continuing to exist
  4. Minimal overhead – Only 8 bytes vs linking to a 9.5MB vision module
  5. Safe updates – When Talk fixes the bug, you can simply delete this file without worrying about breaking other functionality

Alternative: Ignoring the Warning

Since the background blur feature works perfectly with the existing vision_wasm_internal.wasm file, you could simply ignore this warning until Talk releases a fix. It’s purely cosmetic and doesn’t affect any functionality:

  • Background blur works correctly
  • Video calls function normally
  • All WASM features are operational

However, the placeholder file fix only takes a few seconds and provides a clean admin panel. When Talk releases an update that fixes the health check, you can simply remove the placeholder:

rm /var/www/nextcloud/apps/spreed/js/tflite.wasm

For Nextcloud Developers

This is a bug that should be fixed in the Talk/Spreed app. The health check code in lib/SetupCheck/BackgroundBlurLoading.php needs updating to check for the actual WASM files used by the application (vision_wasm_internal.wasm) rather than the obsolete tflite.wasm.

A proper fix would be:

// Check for any existing WASM file instead of hardcoding an obsolete one
$wasmFiles = ['vision_wasm_internal.wasm', 'vision_wasm_nosimd_internal.wasm', 'olm.wasm'];
foreach ($wasmFiles as $file) {
    if (file_exists($appPath . '/js/' . $file)) {
        $url = $this->urlGenerator->linkTo('spreed', 'js/' . $file);
        // run existing check
        break;
    }
}

If you encounter this issue, consider reporting it on the Nextcloud Talk GitHub repository.

Conclusion

This issue is a perfect example of how health checks can become outdated when code is refactored. While the warning message suggests network configuration problems, the actual issue is simply a reference to a renamed file. Once you understand the root cause, the fix is straightforward.

The background blur feature itself works perfectly in Talk 22.0.4+ – it’s just the health check that needs updating. The minimal placeholder WASM file provides a clean, future-proof workaround that won’t conflict with future Talk updates. When the developers fix the health check, you can simply delete the 8-byte placeholder file.

Remember: The warning doesn’t mean your WASM support is broken – it just means the health check is looking for the wrong file. Your background blur feature is working fine!

What Happens When Talk Fixes This Bug?

When Nextcloud Talk releases an update that fixes the health check (likely by checking for vision_wasm_internal.wasm instead of tflite.wasm), you have two options:

  1. Keep the placeholder – It’s only 8 bytes and won’t cause any issues
  2. Remove the placeholder – Simply delete it: rm /var/www/nextcloud/apps/spreed/js/tflite.wasm

If Talk ever implements actual TensorFlow Lite functionality and ships a real tflite.wasm file, the update process will automatically replace your placeholder with the real file.

Similar Posts