Fedora no permission to user home in mount

fedoralinuxmountpermissionsssh

I created a user to use for backups with FTP. I moved the home directory to a mounted drive and gave the user permission to rwx using ACLs. User has a shell, user has a password but when I log into the server using the user through SSH. I get the following error.

Could not chdir to home directory /mnt/NAS/nextcloud_data/linuxman/files/PUSCraft/Backups: Permission denied
-bash: /mnt/NAS/nextcloud_data/linuxman/files/PUSCraft/Backups/.bash_profile: Permission denied

Folder permissions are as follows:

drwxrws---+  6 mcbackup mcbackup       4096 Jul 12  2020  Backups

And this is the ACL configuration:

# file: Backups
# owner: mcbackup
# group: mcbackup
# flags: -s-
user::rwx
user:linuxman:rwx
user:mcbackup:rwx
user:1002:---
user:1003:---
user:1004:---
user:1005:rwx
user:1006:---
group::rw-
mask::rwx
other::---
default:user::rwx
default:user:linuxman:rwx
default:user:mcbackup:rwx
default:user:1002:---
default:user:1003:---
default:user:1004:---
default:user:1005:rwx
default:user:1006:---
default:group::rw-
default:mask::rwx
default:other::---

I don't know much SELinux but I did not see any booleans that may cause issues, to my knowledge.

Any ideas what I'm missing here?

Update: Forgot to mention, the user in question is mcbackup.

Update 1: I looked at the SELinux contexts and stuff of the default home directories and added it to mcbackup's home folder

sudo chcon -r user_home_dir_t Backups

Still getting the same permission error when logging into SSH.

Best Answer

I order to access files in a given directory, you need the appropriate access to the individual file(s) (read and/or write, depending on what you're doing with them), and also at least execute (aka "search") access to the directory and all of the directories on the path to it. If you don't have at least execute access to a particular directory, you can't touch anything within it (including subdirectories). (Note: you need read access to list the contents of a directory, but if you already know the name of the item you want, that's not strictly needed.)

In this case, it looks like the problem was missing access to the /mnt directory (and therefore everything inside it). This is rather unusual; I'm used to /mnt having read and execute allowed for everyone, something like this:

$ ls -ld /mnt
drwxr-xr-x 2 root root 4096 Sep 25  2019 /mnt

...but if you want it locked down for some reason, granting access via an ACL will do the trick.

Related Question