Arch Linux User Repository

@edh - That's not the answer I was hoping for (I was really hoping we could get it to launch without xwayland), but at least I know I'm not missing something.

Some ~/.config/zoomus.conf updates:

• SSO Login: I don't have qt5-webengine installed, and the ebeddedBrowserForSSOLogin line doesn't exist in my config zoomus.conf. SSO login works just fine (issues with Firefox containers aside).
• Audio: I am using Pipewire via pipewire-pulse. system.audio.type defaulted to alsa for me (or I changed it without realizing it). I probably could have installed pipewire-alsa and fixed my issues, but I set system.autio.type=pulse (a lucky guess) and this worked. This should work for anyone using straight PulseAudio as well.

If anyone finds documentation on ~/.config/zoomus.conf, please let us know.

@DukeHarris - no, qt6-wayland does not help as my error message is:

Client: Breakpad is using Single Client Mode! client fd = -1
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

Mentioned ~/.zoom/logs/zoom_stdout_stderr.log didn't contain any Qt-related issues Besides, I have already qt6-wayland package installed. Still same error and Zoom won't start. Also I have nVidia GPU. Computers without nVidia GPU there will that chrome-sandbox SUID trick help but not with nvidia GPU.

@zeroconf I had the same issues you're describing and managed to fix them by installing qt6-wayland

Zoom would also simply not start for me and I found this in ~/.zoom/logs/zoom_stdout_stderr.log:

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

This brought me to https://wiki.archlinux.org/title/Wayland#Qt which mentions installing qt5-wayland or qt6-wayland for Wayland support in Qt.

I hope this helps

Still having issues with v5.14.2-1 in same laptop, where initially reported. My installation permissions and issues are written here. The previous test was done in desktop PC, where I somehow succeeded to run Zoom 5.14.0 - possibly because there is no nVidia GPU but only integrated Intel one (Intel HD Graphics 530). Currently using flatpak version (which is still v5.13.11.1288) as a quick workaround on that laptop with dual GPU (Intel, nVidia but nVidia is in use). Thank you for clean build tutorial but for now didn't have enough time to hack. Found similar issue on zoom community forum but disabling sandbox (zoom --disable-gpu-sandbox) didn't help either, even SUID were or were not applied to /opt/zoom/cef/chrome-sandbox. Also I removed ~/.zoom/ folder before each attempt to start zoom. Direct link to my post in Zoom forum with more detailed information about my hardware on different PCs. Also counterpart post in nVidia forum.

zeroconf: glad you got it working too, and good callout on the new version - hopefully this manual setuid business won't be necessary much longer.

i recommend https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot for more information on clean chroot building - there are helper scripts in the devtools package, or if you prefer you can set up the chroots manually and build from them.

@ItsQuote - yes, sounds like that was the issue.

initially:

stat -c '%A %a %U %G %n' /opt/zoom/cef/chrome-sandbox 
-rwxr-xr-x 755 root root /opt/zoom/cef/chrome-sandbox

then adding SUID

sudo chmod 4755 /opt/zoom/cef/chrome-sandbox

then checking:

stat -c '%A %a %U %G %n' /opt/zoom/cef/chrome-sandbox 
-rwsr-xr-x 4755 root root /opt/zoom/cef/chrome-sandbox

... and Zoom is working again. Even didn't need to wipe ~/.zoom/ folder.

I understand, that this is probably Zoom own issue. For now is already version 5.14.2 (2046) out and currently already flagged as out of date. Perhaps new version has that permission issue fixed already. If anyone has reported that issue to Zoom. That's a good question, how such reporting is possible to Zoom. At least from Zoom website didn't find a way to report a bug (or any other issue) for free to Zoom. Looks like paid support allows to do that...

If any useful tutorial exist for clean building, it might be helpful.

zeroconf: yay is not your package manager, pacman is. pacman is not responsible for building packages, that's what makepkg and its friends are for. it would be more accurate to state this is a problem with Zoom, since the "build" very simply repackages upstream's archive. neither pacman nor makepkg have much say in how the binaries are produced in this case.

that being said: i too have been running into issues with Zoom dumping core as soon as it started, which seemed to be related to the bundled libcef.so. building in a clean chroot and wiping out ~/.zoom/ finally produced console output that indicated /opt/zoom/cef/chrome-sandbox was not setuid, and after "sudo chmod 4755 /opt/zoom/cef/chrome-sandbox" it began loading normally. is there anything in your omitted console output or your journal that might indicate a similar problem?

Not building manually (have never done it), using package manager to install packages. If we really need abandon package manager and start building manually - this renders package management useless. Tried:

yay --cleanmenu --rebuild -S zoom
rm -fr .zoom/
zoom

... still nothing - Zoom won't start.

@cjm In general it is a good idea to build in a clean environment (preferably a chroot). Cleaning up the environment however is not the job of the PKGBUILD.

@gdower Thank you! Deleting pkg/ and src/ before building the package finally fixed my undefined symbol error. (It seems to me the PKGBUILD should do that if necessary.)

Seems like the "hide floating meeting controls" option is missing and has been disabled in zoom-5.14.0. Anyone know if there's any way to re-enable that? Maybe in a config file? It's a nuisance to have the meeting controls hiding a big chunk of my screen share.