carlanbro I try to do my part [no one from solus has yelled at me yet at least and they will🙂] for the Beta-XFCE bug reporting and I have dispatched a lot verbal diarrhea at devtracker re: XFCE---and you are probably right. 70% is about right. An update wrecked my Plank for the second time but all the other bugs (70%) are just Beta-related or I found a workaround, or I went to other Solus DEs (and other distros) to repicate, and I could, thereby making my bug report not XFCE-related. I document that there.
So far I can only blame the updates for one thing out of a handful. Unlike you, I am not sure I introduced the problem but use the search function above for 'rocm' and the top three are horror stories with the last post 2 years ago for any of them.
---maybe those 3 threads may give you a place to troubleshoot

      carlanbro Is it just a browser thing? Can you copy files from a USB for instance, or save a file to your documents directly from Libre Office.
      Just wondering if it could be a /home/ ownership thing. There are chown commands that could fix that, but worth establishing that ownership is the problem before dabbling with powerful commands.

        brent I just ended up reinstalling it, I didn't have much to redo anyways since it don't put many files into Linux since I hop around a lot. Seems to work ok now.

          I have the same problem after upgrading. Firefox screenshots save without issue to the "Downloads" directory (probably because they save directly to the specified directory and never prompt the user) and Thunar can be launched from the "Downloads panel" to see the downloaded file. I can also open files in Firefox from Thunar without issue.

          The issue seems to be limited to the save/open file dialog.

          journalctl reports the following when I try to save something:
          systemd[709]: Starting xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)...
          xdg-desktop-por[8136]: cannot open display:
          systemd[709]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
          systemd[709]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
          systemd[709]: Failed to start xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation).
          xdg-desktop-por[1137]: Backend call failed: Could not activate remote peer: startup job failed.

            random start with sudo eopkg check maybe.
            If it is a fresh install check disc SMART data and also check RAM health. Make sure all updates have been installed.
            An older install that has been 'experimented' with might need a full wipe disc and start again as @carlanbro just posted.

              I've since rolled back and upgraded only the systemd package (and a few dependencies it pulled). It indeed broke things as I expected. My guess is that some variable is not being set correctly after this upgrade.

              I am open to suggestions to further troubleshoot this issue as I am out of my depth.

                random I've since rolled back and upgraded only the systemd package (and a few dependencies it pulled). It indeed broke things as I expected.

                that's some good detective work (after all, you tried trial and error method, must've took some patience) and may explain even more of the Beta's anomalies that I'm finding. Regressing systemd to an older package fixed or broke your right click xfce issue?

                    brent I regressed the whole system which fixed the issue and then upgraded only the systemd package to the latest version (to check if my suspicions were right) and everything broke again.

                      Sebastian Done.

                      After a bit more digging I found the problem. The latest systemd update (re)creates the 50-systemd-user.sh file but without the execute permission. The script doesn't run and the DISPLAY and XAUTHORITY variables are not imported into the systemd user manager (hence the cannot open display message from my journalctl logs).

                      The problem is solved by making the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh file executable again with chmod +x.

                      I hope this also proves to be the solution to the plank problems @brent has.

                          random I replied in your bug ticket to Staudey:
                          "working in budgie rest of night. will try this in xfce for #1657 tomorrow and report back. thanks for bringing it to my attention (you and Random)."

                          great research,

                          thats
                          cd /etc/X11/xinit/xinitrc.d
                          sudo chmod +x 50-systemd-user.sh
                          --do I have that right? and thank you again.