Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
in my Linux machine - red-hat
I successfully to login to different users as the following
su - userC
[machine@Linux ~]$ pwd
[machine@Linux ~]$ /Users/userC
but only in one user I get the following
su - UserA
Creating directory '/User/UserA'.
could not open session
please advice from where I get the message "could not open session"
what could be the problem ?
root@hostname # su - oracle
could not open session
root@hostname # grep oracle.*nofile /etc/security/limits.conf
oracle - nofile unlimited
set nofile in limits.conf to some number instead of unlimited:
root@hostname # vi /etc/security/limits.conf
root@hostname # grep oracle.*nofile /etc/security/limits.conf
oracle - nofile 65536
root@hostname # su - oracle
-bash-4.1$ id
uid=201(oracle) gid=5504(oinstall) groups=5504(oinstall),251(dba),5502(asmdba),5505(oper)
-bash-4.1$
cat /proc/sys/fs/file-max # 512000 Which suggests you need the line oracle - nofile 512000 instead
Mar 1, 2018 at 13:58
This is what worked for me, in my case su was working for some users. So, I checked the content of /etc/pam.d/su and it had the following two lines :
session include system-auth
session optional pam_xauth.so
I commented out the first one, restarted the session and it worked.
session include system-auth in pam.d/su OR the nofile limits in /etc/security/limits.conf the Su would start working again.
Feb 26, 2020 at 19:34
commenting "session required pam_limits.so" in all files in "/etc/pam.d" solves
(OL7.7)
sed -i -r 's/^(session\s+required\s+pam_limits.so)/#\1/' /etc/pam.d/*
If "nofile" is set to "unlimited" in /etc/security/limits.conf (or in files in limits.d) then the user cannot login.
Commenting out 'session include system-auth' worked for me.
env: docker oraclelinux:latest, after installing oracle-database-server-12cR2-preinstall.x86_64 package.
I was playing with docker and oraclelinux:7-slim, to install an Oracle Database. After installing oracle-database-preinstall-19c package, I stopped being able to su - into oracle account. Here some talk about "nofile unlimited" in limits.conf. I tried that and it didn't work. Commenting session include system-auth line in /etc/pam.d/su works.
However, before I installed the package, the configuration was all the same and I was able to do su - oracle. Even after installed the package, if I create a new user belonging to the same groups as oracle I can su into their account. So it had to be something that the package changed.
After some investigation I discovered that the packages installs oracle-database-preinstall-19c.conf in /etc/security/limits.d/ and that file has all the oracle limits configuration. Only when I commented the following line, was I able to su into oracle account:
oracle hard memlock 134217728
This sets the memlock to 128Gb.Tried to put smaller values without success. Only when I commented.
So now you know that this is the cause. But of course, if you comment session include system-auth line in /etc/pam.d/su it works too.
Make sure pam_limits.so line has tabs like this:
session^I^Irequired^Ipam_limits.so$
When this line is added, the tabs are important.
sed -i '$a session^I^Irequired^Ipam_limits.so' /etc/pam.d/su
If the tabs are missing, then you will see something like this:
[ azureadmin]# su - ALOGIN
Last login: Fri Jun 11 08:42:32 CDT 2021 on pts/0
su: cannot open session: Permission denied
I came across this same error. "sudo su -" did not work, nor did "su -", however "sudo -iu root" or "sudo /bin/bash" did "work" ("sudo /bin/bash" isn't quite doing the same thing, in terms of environment variables, so I feel a little dubious calling this a work around). The answer wasn't the "nofile" limit, nor was the answer the permissions on /etc/pam.d/system* files. The answer in my case was that /var/log/btmp was corrupted.
# cat /dev/null > /var/log/btmp
Some times it happens to me with error "could not open session" and It works with just type
sudo bash
getent passwdand are you using LDAP, flat files, or something else? It really looks like UserA's shell is set to/sbin/nologin/Users/userCand/Users/UserAa typo? Intentional? The problem?