Keep being told "Permission Denied" for executables in home directory

[thermatix]

I own all the files, same again with the group, I’ve ran:

sudo chown -R thermatix:thermatix ~

I’ve also set within the directory the executable bit plus same again for the executable themselves.

bit but still “permission denied” on top of that I’m getting other weird issues.

I’m sometimes getting permission denied when trying to install stuff with yay (the errors occur within /home/thermatix/.cache)

For example, trying to install proton, one of the failures:

==> Starting build()...
/home/thermatix/.cache/yay/lib32-lzo/PKGBUILD: line 23: ./configure: Permission denied
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: lib32-lzo-exit status 4

and steam errored with this:

$ steam
bin_steam.sh[12217]: Setting up Steam content in /home/thermatix/.local/share/Steam
gio: Setting attribute metadata::trusted not supported

using getfacl on one of the executables:

$ getfacl .local/bin/fan_up 
# file: .local/bin/fan_up
# owner: thermatix
# group: thermatix
user::rwx
group::r-x
other::r-x

I’m not using SeLinux nor app-armour.

Also note, the home directory is from my previous install of EndevourOS, I had to re-install after something went super-wrong last Thursday (I think).

[dalto]

Can you share the full output from a command where it is failing. Also, an ls -l of that file.

[thermatix]

$ .local/bin/fan_up
bash: .local/bin/fan_up: Permission denied

I also added an example of a yay install failure to the OP.

[dalto]

Can you share the output of findmnt --real

Let’s see if something is mounted noexec

[thermatix]

Ok, that’s weird according to this:

$ findmnt --real
TARGET               SOURCE         FSTYPE      OPTIONS
/                    /dev/nvme1n1p3 ext4        rw,noatime
├─/stuff             /dev/nvme0n1p1 ext4        rw,relatime
├─/run/user/1000/doc portal         fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
├─/efi               /dev/nvme1n1p1 vfat        rw,relatime,fmask=0137,dmask=0027,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
└─/home              /dev/nvme1n1p2 ext4        rw,nosuid,nodev,noexec,relatime

home is mounted as noexec, but in the fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=9B43-5C33                              /efi     vfat    fmask=0137,dmask=0027   0 2 
UUID=de1b1496-46d4-4a1c-801f-419c14089008   /        ext4    noatime                 0 1 
tmpfs                                       /tmp     tmpfs   noatime,mode=1777       0 0 
LABEL=home                                  /home    ext4    users                   0 0 
LABEL=stuff                                 /stuff   ext4    nofail                  0 0 

it’s not, same in KDE-Partition manager which is why I didn’t consider that.

[dalto]

users implies noexec.

That is why it isn’t working.

[thermatix]

It does? I thought user’s just mean “user’s can mount and unmount at will”

EDIT: Or at least that’s that the option in KDE-partition manager seems to imply.

[dalto]

@thermatix

I thought user’s just mean “user’s can mount and unmount at will”

Are you thinking of user? That is what that does.

That being said, user also implies noexec

If you just /etc/fstab to noatime instead, it should work.

[thermatix]

Why would it imply that?

[dalto]

@thermatix

Why would it imply that?

Because that is what it says in the documentation?

Or more generally, for security purposes.

That being sense, it makes very little sense to mount /home with user or users

[thermatix]

Well now I understand that, I agree, it doesn’t .

Thank you for your help.