I don't own permissions to /.local/bin, what's going on?


I backup my laptop almost daily with Pika Backup, and I recently got an error during my backup saying :

Backup completed with warnings, Warning: /home/scott/.local/bin: dir_open: [Errno 13] Permissions denied: ‘bin’

So I took this up with the Pika developer thinking it’s an issue with Pika, however they mentioned that it’s a bit weird I don’t own my own permissions for ~/.local/bin and told me to mention it here instead as it appears to be a Fedora issue. I’m running Fedora 39 Gnome 45.4 Workstation fully up to date.

I never had an issue before with permissions and updating my backups, so I assume a recent Fedora update changed this perhaps? Or is there something else going on here? Can anyone else running an up to date Fedora comfirm if they too have permissions or not for their ~/.local/bin directory?

When I use Nautilus to look at my /.local/bin directory, it askes me to enter my user password before I can enter and view the bin folder, which upon inspection only has one file inside it called kms-server-proxy

My Fedora 39 install is very fresh and new, I did a reinstall about 2-3 weeks ago and I don’t edit much if anything my setup is essentially stock, no extensions even at the moment.

Did a recent Fedora update change permissions unexpectedly, is this intended, or is something else doing on here? Would appreciate any help into this matter, thank you.

Locating the bin directory, you can see by the lock icon and cross X I dont have permissions on my own bin directory, even though I have in the past:

Upon entering the ~/.local/bin directory, all that is there is this one single file:

For slightly more detail into the error, also here is a link to the bug report I mentioned in Pika: Backup Warning Issues on Fedora 39 (#472) · Issues · World / Pika Backup · GitLab

EDIT: Flatpak dev/maintainer updated the flatpak with a fix in the bug report linked here, everything is back to normal again!

It is very much preferred that whenever possible details are posted with cli output using copy & paste from your screen. Doing so makes the details searchable for those hunting for answers and also provides much more detail for our analysis.

Please post the output of ls -ldZ ~/.local/bin and ls -lZ ~/.local/bin so we may see the actual ownership and permissions of the directory and the file.

At first glance it would seem possible that kms-server may have been run the first time as root (or using sudo) so that directory was not created by your user but possibly by some other user.


Well that’s concerning as I’m the only user of my laptop…

scott@fedora:~$ ls -ldZ ~/.local/bin
drwx------. 1 root root unconfined_u:object_r:gconf_home_t:s0 32 Feb 14 23:59 /home/scott/.local/bin`
scott@fedora:~$ ls -lZ ~/.local/bin
ls: cannot open directory '/home/scott/.local/bin': Permission denied

edit: when I search ddg/google for “kms-server-proxy” in quotes, literally nothing comes up in the search, and no I don’t use Windows or any Microsoft products.

The root user, if you’ve run the command with sudo the root account would then create the directory if it were not there.

If the change was recent it could be in the logs. Super + Logs to see the log viewer

I don’t know what I should be searching for or what to look for exactly? But I tried searching for “kms” and didn’t get anything but this:

kms-server-proxy is almost certainly this, which is used as part of the GPU Screen Recorder flatpak. It intentionally installs itself as root in that directory, which seems a bit broken. You can open an issue about that: Issues · flathub/com.dec05eba.gpu_screen_recorder · GitHub


Oh wow this is the answer, as I do have GPU screen recorder flatpak installed and there was one or two recent updates to it, but it’s hard to follow their changelog since they don’t use Github or Gitlab, but in any case, thank you for this! Will file a bug report upstream for it.

Bug report: ~/.local/bin directory permission denied error, reason kms-server-proxy · Issue #97 · flathub/com.dec05eba.gpu_screen_recorder · GitHub

When I do a backup with rsync on my home directory, I use sudo because there’s always something in there that my user account doesn’t have permissions to copy.

I could only hope the developer finds a way to do this with Portals. . . This spells more trouble in the future.

If there is always something in there that my user account doesn’t have permissions to copy in your home directory tree then the user seems to be using sudo or doing something as root that creates those items. This is not the way the system is designed to work and seems a user error to do that.

Whatever is created by the user is normally owned by the user. What is created by root is owned by root. It is not intended, nor is it good practice, to use root and create items under the normal users home directory.

This post is now solved after the GPU Screen Recorder dev/maintainer responded to my bug report and updated the flatpak version just now. If this is the first time you’re installing it, the problem with the permissions will have already been fixed. If you are like me and have installed GPU Screen Recorder before the update, the developer said to run this command to get permissions and then the issue should be solved:

sudo chown $USER:$USER ~/.local/bin