There are a lot of questions with similar titles. I believe I have checked them all before asking this question.

My error is su: Permission denied and the user switch is not completed. Here are the details.

ssh admin@remote-machine
su --login myuser
su: Permission denied
(the password is correct)

RESULT: failed to switch users

However, the following does work, even though it reports a minor error:

su --preserve-environment myuser
bash: /home/admin/.bashrc: Permission denied

RESULT: succeeds to switch users

Also, plain su myuser without any parameters works. These variants also work:

su -P myuser
su -s /bin/sh myuser

Even though I have a work-around, I want to understand this issue. Also, my preferred form of the command, su - user is the one that does not work. This issue only affects one remote device, even though I have several that appear to be configured identically. They all run Arch Linux.

I'm not using SELinux. From reading the other questions, I checked a few things.

user@remote-machine [/home/myuser] # ls
total 13904
drwx--x---+ 1 myuser myuser    3210 Feb 18 16:00  .
-rw-r--r--  1 myuser myuser     396 Aug 13  2018  .bashrc

# getfacl /home/myuser/
getfacl: Removing leading '/' from absolute path names
# file: home/myuser/
# owner: myuser
# group: myuser

# ls /home/admin/.bashrc
-rw-r--r-- 1 admin admin 624 Apr 17 17:08 /home/admin/.bashrc

less /etc/passwd
myuser:x:1000:1000:myuser myuser:/home/myuser:/bin/bash

In /etc/pam.d/su the following line is commented out (which is the default):

# auth       required     pam_wheel.so use_uid

EDIT: added info as requested.

First, I did a diff -rw on /etc/profile.d/ between this system and a similar system that does not have this su -l problem. There are no differences. Both contain only the standard Arch Linux scripts in /etc/profile.d/.

There is one change in /etc/profile itself from the stock Arch Linux file. But this change is present in both the correctly working system and the one with the su -l problem. The only change in /etc/profile is umask 006.


# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[[ $DISPLAY ]] && shopt -s checkwinsize


case ${TERM} in
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion

The files shown below are in the user account I issued the su command from. But this issue affects any user changing to any other user. I don't see any of the user accounts with modified files (for ~/.bash_profile, ~/.bash_login, and ~/.profile). There is no .bash_login in any account or in /etc.

Both of the next files are bare-bones.


[[ -f ~/.bashrc ]] && . ~/.bashrc


# If not running interactively, don't do anything
[[ $- != *i* ]] && return

In one account, ~/.bashrc has:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
  • the aliases in .bash_aliases all look OK. The issue also affects users with no aliases defined.
  • /etc/security/limits.conf - no lines (other than comments both working & non-working devices have the same empty file)
  • /etc/securetty - stock Arch Linux (no changes to file & both working & non-working devices have the same lines)
  • /etc/passwd - 644 perms
  • /etc/ - 755 perms

SOLUTION: /etc/pam.d/su-l (but not any of the other files in /etc/pam.d/) required pam_wheel.so use_uid. See accepted answer for more. Now that this is resolved, this question contains a comprehensive checklist for this issue. Hopefully it will be a good reference for others.

2 Answers 2


I suspect there is something wrong with one of the scripts which get called when you spawn a login shell, as opposed to those called by a non-login shell.

Have a look at the INVOCATION section of man bash

Mine reads:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.


When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.

For the "minor error" bash: /home/admin/.bashrc: Permission denied.

This is because the HOME environment variable of the admin user is coming access and the myuser user does not have permission to access the $~/.bashrc, which is what bash does when spawning a new shell.

  • I had a chance to test further, including testing multiple different user accounts on this device. This affects all users when doing su - anyotheruser. I will update the question with the contents of ~/.bash_profile, ~/.bash_login, and ~/.profile.
    – MountainX
    May 16, 2020 at 23:43

I did a diff -rw on /etc/pam.d/ between this system and a similar system that does not have this su -l problem. I found /etc/pam.d/su-l had this line uncommented:

auth           required        pam_wheel.so use_uid

It is normally commented so as to not impose this requirement. None of the other similar files in /etc/pam.d/ had this line uncommented, hence the inconsistent behavior of different variants of the command.

I solved the issue by commenting that line:

# auth           required        pam_wheel.so use_uid

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.