scoonma Posted August 10, 2006 Report Share Posted August 10, 2006 Hi all, I recently stumbled over a strange problem of similar type Urza reported of: Unable to login as *any* user, I still can login to the system (Mandriva 2007 cooker) as root. Trying to login as normal user from console (i.e. "login: " prompt, the system kicks me out immediately. By lowering processor speed I was able to see the small error message: It says there is no home directory for that user, but it actually exists! There is no kernel message giving any hint on "F-12 console", no valuable information on /var/log/messages or /var/log/secure. When trying to "su <user>" after root login, the only error is "could not open session". By googling I found out that this could be caused by file permissions wrongly set. So I've checked the following (which should be okay, AFAIK): /etc drwxr-xr-x /etc/pam.d drwxr-xr-x /etc/passwd rw-r--r-- /etc/shadow rw------- It does not matter wether trying to use an existing user in /home or after creating a new one with "useradd", so it's likely to be a system wide error. Last option that came to my mind is to use strace. I tried "strace -oout.txt su <user>" and found the following: [...] open("/etc/pam.d/other", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=154, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "#%PAM-1.0\nauth required "..., 131072) = 154 read(3, "", 131072) = 0 close(3) = 0 munmap(0xb7d01000, 131072) = 0 getuid32() = 0 getuid32() = 0 open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340 close(3) = 0 munmap(0xb7d01000, 131072) = 0 time(NULL) = 1155194279 getuid32() = 0 getuid32() = 0 open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340 close(3) = 0 munmap(0xb7d01000, 131072) = 0 open("/etc/shadow", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0600, st_size=831, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:$1$pAlg6jqo$Q4EOt4pn2aApAsq"..., 131072) = 831 close(3) = 0 munmap(0xb7d01000, 131072) = 0 time(NULL) = 1155194279 setfsuid32(501) = 0 setfsgid32(501) = 0 access("/usr/bin/xauth", X_OK) = 0 open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/ld.so.cache", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) getuid32() = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 readlink("/proc/self/fd/0", 0x8055f70, 4095) = -1 EACCES (Permission denied) fstat64(0, {st_mode=S_IFCHR|0600, st_size=makedev(0, 0), ...}) = 0 stat64("/dev/pts", 0xbff16878) = -1 EACCES (Permission denied) open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 EACCES (Permission denied) getuid32() = 0 time(NULL) = 1155194279 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) socket(PF_FILE, SOCK_DGRAM, 0) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 EACCES (Permission denied) close(3) = 0 write(2, "could not open session\n", 23) = 23 exit_group(1) = ? Any ideas please? Greetings, scoonma [moved from Software by spinynorman] Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted August 10, 2006 Report Share Posted August 10, 2006 Check the permissions on the home directory. Does it exist? Also, check /etc/passwd by doing this: [ian@europa ~]$ cat /etc/passwd | grep ian ian:x:500:500:Ian Walker:/home/ian:/bin/bash as I have here filtering by my user. You can see my home directory is /home/ian. So if this isn't pointing to where it should be, do this: usermod -d /home/ian ian if that doesn't work, we need to see if the permissions are screwed: [ian@europa home]$ ls -l | grep ian drwxr-xr-x 56 ian ian 2544 Aug 10 13:06 ian/ so, as you can see, mine is set correct, but maybe your home has other details. Reset it with: chown -R ian:ian /home/ian and that should reset all the files in /home/ian and make sure you're back up and running. Quote Link to comment Share on other sites More sharing options...
scoonma Posted August 10, 2006 Author Report Share Posted August 10, 2006 Hi Ian, thx for your fast response! I've done/re-checked what you suggested (/home dir exists, has correct permissions, ...), but unfortunately it does not help. The clue must be located elsewhere. When being root, "su clamav" or "su adm" (or any other user) do result in the very same error: "could not open session". This is why I'm so puzzled. Regards, scoonma Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted August 10, 2006 Report Share Posted August 10, 2006 What shell has been assigned to each user? This is at the end of each line in /etc/passwd. For normal users to login, it would be /bin/bash. Quote Link to comment Share on other sites More sharing options...
ffi Posted August 10, 2006 Report Share Posted August 10, 2006 (edited) I have seen similar error messages after I got a bit too thorough deleting files from my home dir ( I wanted to go back to the default setting, so had deleted most .dirs) did you try creating a fresh user? Edited August 10, 2006 by ffi Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted August 10, 2006 Report Share Posted August 10, 2006 Ah, ffi made me think of something. You might need to look to see if your .bash files exist in your /home/username directory. If not, you can always copy them over again from /etc/skel directory. Quote Link to comment Share on other sites More sharing options...
scoonma Posted August 11, 2006 Author Report Share Posted August 11, 2006 (edited) Thx for your hints! However, the error resists. Shell is /bin/bash, (as normal). The .bash* files within /home/user dir are all intact (and are rarely touched). When creating new users, their accounts suffer from the same problem (i.e. su/login not possible). The corresponding directories are created though, also the defaults from /etc/skel are copied. I did some further googling and found this page: http://www.wlug.org.nz/EACCES. It states that the EACCES error mentioned above is likely being caused by file permission conflicts, but I don't know which places I still haven't checked. Last "candidate" was /bin/bash; I changed permissions from rwx------ to rwxr-xr-x, but this didn't help either. The offending place must be rather central, but not influencing the root acount in this regard. Hm. Edited August 11, 2006 by scoonma Quote Link to comment Share on other sites More sharing options...
aioshin Posted August 11, 2006 Report Share Posted August 11, 2006 (edited) try to chmod 755 the /home dir chmod 755 /home then try to chown your $HOME dir chown user.user -R /home/user user is your normal username and see if that helps.. Edited August 11, 2006 by aioshin Quote Link to comment Share on other sites More sharing options...
scoonma Posted August 11, 2006 Author Report Share Posted August 11, 2006 Hi aioshin, you wrote: try to chmod 755 the /home dir then try to chown your $HOME dir Tried, but it didn't help. I'm suspecting an issue with pam now. But re-installing passwd and pam didn't help either. Too bad! scoonma Quote Link to comment Share on other sites More sharing options...
ffi Posted August 11, 2006 Report Share Posted August 11, 2006 Did you update all files in /etc to their new versions? I use etc-update available through either main or contrib.... Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted August 11, 2006 Report Share Posted August 11, 2006 I use that tool in gentoo, really cool way of doing it. My method I learnt in Mandrake/Mandriva: updatedb && slocate rpmnew and you'll get a load of .conf.rpmnew files listed, and you can then replace them where necessary. Quote Link to comment Share on other sites More sharing options...
aioshin Posted August 11, 2006 Report Share Posted August 11, 2006 if its ok, can you post the result of ls -l / and ls -l /home just rename your users dir Quote Link to comment Share on other sites More sharing options...
scoonma Posted August 11, 2006 Author Report Share Posted August 11, 2006 I've used etc-update but this was doing no good. After rebooting, the whole filesystem was crashed beyond repair. There must have gone something deeply wrong. Now I've reinstalled from scratch (everything except /home) and the system runs fine again. But I hate this sort-of windumb method for fixing... Thx nonetheless! scoonma Quote Link to comment Share on other sites More sharing options...
Gowator Posted August 11, 2006 Report Share Posted August 11, 2006 Probably a file ownership prob in the .kde or tmp dir. You could su to a user... what aioshin said should have fixed it but it might have given an error message you missed? Also a full /home will do this as will a corrupt file in the .kde The best thing as someone already said is create a new user. Apart from anything else having a spare test user is not a bad idea for playing with themes and such anyway. Quote Link to comment Share on other sites More sharing options...
ffi Posted August 11, 2006 Report Share Posted August 11, 2006 I've used etc-update but this was doing no good. After rebooting, the whole filesystem was crashed beyond repair. There must have gone something deeply wrong. Now I've reinstalled from scratch (everything except /home) and the system runs fine again. But I hate this sort-of windumb method for fixing... Thx nonetheless! scoonma Sorry :sad: Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.