The screen share fails silently
You click "Share Screen" in Zoom. The window turns black. Or OBS shows a frozen desktop. You check the system tray and PipeWire is running. You restart the app. Nothing changes. The screen sharing dialog hangs, then fails silently. This is the classic Wayland capture failure on Fedora.
The problem is rarely a broken installation. It is usually a mismatch between the application's capture method, the portal service state, or a sandbox permission missing in a Flatpak wrapper. Fedora enforces a strict security model where applications cannot touch the screen directly. They must request a stream through a standardized protocol. When that chain breaks, the share dies.
How Wayland captures the screen
Wayland compositors like Mutter refuse direct screen access for every application. The security model treats the screen as a protected resource. Applications cannot just read the framebuffer. They must request a stream through a standardized portal.
Think of the portal as a receptionist. The application asks the receptionist for permission to record the screen. The receptionist shows a system dialog asking you to approve. If you approve, the receptionist hands the application a secure stream via PipeWire. PipeWire acts as the media router that negotiates the format and delivers the video data.
If the portal service is inactive, the application is trying to use an X11 fallback that Wayland blocks, or the application is running inside a Flatpak sandbox without screen permissions, the request fails. The error usually manifests as a black screen, a frozen image, or a generic "failed to start" message in the app.
Check the portal status before you touch application settings. The portal is the gatekeeper.
Update the PipeWire stack
Fedora ships PipeWire by default, but the portal implementation and WirePlumber session manager evolve rapidly. A stale version causes handshake failures with newer Electron apps like Teams or Zoom. Fedora's release cadence is six months, and PipeWire updates land frequently in minor releases.
Run the update to pull the latest fixes. Use --refresh to force a metadata check. This ensures you catch repository updates you might have missed if the cache is stale.
sudo dnf upgrade --refresh pipewire wireplumber pipewire-pulse pipewire-x11grab # WHY: --refresh forces metadata check to catch repo updates you missed. pipewire-x11grab is required for X11 app compatibility on Wayland.
systemctl --user restart pipewire wireplumber # WHY: User services need a restart to pick up library changes. systemctl --user targets the session scope, not the system daemon.
Log out and log back in after the update. PipeWire caches state in memory. A logout clears stale locks and resets the D-Bus session bus permissions.
Fix application-specific backends
Some applications default to XWayland or X11 capture methods even when running on Wayland. You must force them to use the native backend.
OBS Studio
OBS Studio defaults to XShm on some builds. Switch the source to PipeWire.
Open OBS. Add a new source. Select "Screen Capture (PipeWire)". Choose the desktop or window. If you select "Screen Capture (XShm)" or "X11grab", OBS tries to use legacy methods that Wayland blocks. The preview will show a black screen.
Zoom and Microsoft Teams
Electron-based apps like Zoom and Teams may launch in XWayland mode by default. Force Wayland mode via command-line flags.
Launch Teams from the terminal with the ozone flags. This forces the Chromium backend to use the native Wayland compositor.
teams --enable-features=UseOzonePlatform --ozone-platform=wayland # WHY: Forces the Chromium backend to use the native Wayland compositor instead of XWayland. This enables native screen sharing support.
For Zoom, check the settings. Some builds have a "Use Wayland" toggle in the advanced settings. If the toggle is missing, launch Zoom with the environment variable ZOOM_WAYLAND=1.
ZOOM_WAYLAND=1 zoom # WHY: Tells the Zoom wrapper to prefer the Wayland backend. This variable is respected by the official Fedora package.
Verify the app is running on Wayland. Check the process environment.
echo $XDG_SESSION_TYPE # WHY: Confirms the session type. Output should be wayland. If it returns x11, you are logged into an Xorg session.
Handle Flatpak sandbox permissions
Flatpak apps run in a bubble. They cannot see the PipeWire socket by default. You must grant permissions explicitly. This is the most common cause of screen sharing failure for Zoom, Teams, and OBS when installed via Flathub.
The sandbox blocks everything until you allow it. Grant the screen share permission using flatpak override.
flatpak override --user --socket=pulseaudio --share=screen com.github.obsproject.OBS # WHY: --socket=pulseaudio grants audio access. --share=screen grants the portal permission for screen capture. --user targets the current user's Flatpak config.
Replace the app ID with the correct identifier for your application. Use flatpak list to find the ID.
If you use GNOME Extensions Manager or Flatseal to manage permissions, ensure the "Screen Sharing" toggle is enabled for the app. Flatseal provides a graphical interface for the same overrides.
Restart the Flatpak app after changing permissions. The sandbox rules apply at launch.
Diagnose codec and SELinux blocks
If the portal is active and the app is configured correctly, the failure might be a missing codec or an SELinux denial.
Missing codecs
Some applications require H.264 encoding for screen sharing. Fedora Workstation includes the necessary codecs by default. If you are on a minimal install or a custom spin, you might be missing the encoder.
Install the openh264 plugin. This provides the H.264 encoder required by many video conferencing tools.
sudo dnf install gstreamer1-plugin-openh264 # WHY: Installs the H.264 encoder/decoder required by many video conferencing tools. Without this, the app may fail to negotiate a video stream.
Check the journal for codec errors. PipeWire logs negotiation failures.
journalctl -xeu pipewire --user # WHY: -x adds explanatory text for error codes. -u filters by unit. --user reads the session journal where PipeWire runs.
Look for lines mentioning openh264 or codec negotiation failed. If you see Failed to create stream: Connection refused, the portal service is not responding. Check if xdg-desktop-portal is masked or failed.
Oct 24 10:15:30 fedora pipewire[1234]: Failed to create stream: Connection refused
Oct 24 10:15:30 fedora pipewire[1234]: Error: Could not connect to portal: org.freedesktop.portal.ScreenCast
SELinux denials
SELinux denials appear when an application tries to access a socket or file outside its allowed domain. You will see type=AVC messages in the audit log.
Do not disable SELinux. Check if the application is running inside a custom sandbox or if a local policy module is needed.
Search for recent denials related to PipeWire.
sudo ausearch -m avc -ts recent | grep pipewire # WHY: ausearch filters audit logs for Access Vector Cache denials. -ts recent shows events since the last boot. grep isolates PipeWire related blocks.
If you see denials for a standard app like Zoom or OBS, the package likely has a correct policy. The denial might be caused by a misconfiguration. If you see denials for a custom script or local binary, generate a policy module using audit2allow.
type=AVC msg=audit(1715420000.000:123): avc: denied { read } for pid=1234 comm="zoom" name="pipewire-0" dev="tmpfs" ino=5678 scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:xdg_portal_t:s0 tclass=unix_stream_socket
Run journalctl -t setroubleshoot for a one-line summary of the denial and suggested fix. Read the summary before making changes.
Verify the capture works
Launch OBS Studio. Add a "Screen Capture (PipeWire)" source. Select the desktop. If the preview shows your live desktop, the stack is healthy.
If you see a black screen in OBS but audio works, the video codec negotiation failed. Check pipewire logs for codec errors.
If OBS works but Zoom fails, the issue is specific to Zoom's backend. Force Wayland mode in Zoom or check for a Zoom update.
Run the portal test tool to verify the portal responds.
xdg-desktop-portal --help # WHY: Verifies the portal binary is installed and accessible. If this command fails, the portal package is missing.
Check the portal service status.
systemctl --user status xdg-desktop-portal xdg-desktop-portal-gnome # WHY: Verify the portal services are active. The gnome backend handles the permission dialog. If this is inactive, apps cannot request screen capture.
If the portal is inactive, start it manually.
systemctl --user start xdg-desktop-portal xdg-desktop-portal-gnome # WHY: Starts the portal services in the user session. This is rarely needed on a default Fedora install but fixes broken session states.
Choose the right capture method
Use PipeWire screen sharing when you want native Wayland security and smooth capture in modern applications.
Use XWayland capture via pipewire-x11grab when you are running legacy X11 applications that do not support Wayland protocols.
Switch to Xorg session when you need to run proprietary drivers or applications that fundamentally break under Wayland and cannot be patched.
Use Flatpak with --share=screen when you are installing sandboxed applications and need to grant explicit portal permissions.
Trust the portal. If the portal works, the app just needs the right flags.