12
root@frankfurt:~# sudo adduser newuser
Adding user `newuser' ...
Adding new group `newuser' (1001) ...
Adding new user `newuser' (1001) with group `newuser' ...
Creating home directory `/home/newuser' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for newuser
Enter the new value, or press ENTER for the default
    Full Name []: new
    Room Number []: 
    Work Phone []: 
    Home Phone []: 
    Other []: 
Is the information correct? [Y/n] y
root@frankfurt:~# su newuser
Cannot execute /bin/bash: Permission denied
root@frankfurt:~# 

Thanks.

3
  • What about bash execute permission? Post the output of ls -l /bin/bash. Jun 13, 2013 at 9:54
  • output of ls -l /bin/bash -rwxr-xr-x 1 root root 920788 Mar 28 18:37 /bin/bash
    – thirupal.d
    Jun 13, 2013 at 13:47
  • Honestly, no matter what I do, I cannot reproduce this problem. Have you tried testing this on a freshly installed system?
    – Majal
    May 31, 2016 at 6:28

5 Answers 5

18

Change the permission of these folders like this and now you can su to another user.

chmod 755 /
chmod 755 /bin
chmod 755 /lib
2
  • 2
    My problem was solved by doing chmod 755 / What is strange is that I needed to do this after a fresh install of Ubuntu 16.04.1 amd64 Desktop Sep 6, 2016 at 21:34
  • Solved my problems. Somehow my / was 754 - no execute flag. I spent days on this, including a chown to :users on all of /bin.
    – Engineer
    Mar 22 at 0:21
12
+200
  1. Check the permissions of /bin folder

    # ls -ld /bin
    drwxr-xr-x 2 root root 4096 May 27 21:39 /bin
    
  2. Check the permissions of all shells available

    # ls -l /bin/*sh
    -rwxr-xr-x 1 root root 1037464 Sep  1  2015 /bin/bash
    -rwxr-xr-x 1 root root  154072 Feb 17 21:25 /bin/dash
    lrwxrwxrwx 1 root root       4 Sep  1  2015 /bin/rbash -> bash
    lrwxrwxrwx 1 root root       4 Feb 17 21:25 /bin/sh -> dash
    lrwxrwxrwx 1 root root       7 Aug 19  2015 /bin/static-sh -> busybox
    

    Some are links that we should check their targets

    # ls -lL /bin/*sh
    -rwxr-xr-x 1 root root 1037464 Sep  1  2015 /bin/bash
    -rwxr-xr-x 1 root root  154072 Feb 17 21:25 /bin/dash
    -rwxr-xr-x 1 root root 1037464 Sep  1  2015 /bin/rbash
    -rwxr-xr-x 1 root root  154072 Feb 17 21:25 /bin/sh
    -rwxr-xr-x 1 root root 1964536 Aug 19  2015 /bin/static-sh
    
  3. Try another shell

    The best is busybox because it is a static build (No .so library needed)

    su newuser -s /bin/static-sh
    

    Next is dash, low dependencies and installed by default

    su newuser -s /bin/dash
    
  4. Check permissions of libraries and their parent folders, you can get list using ldd

    # ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007ffdefb5a000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f714bbbd000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f714b9b9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f714b5ef000)
        /lib64/ld-linux-x86-64.so.2 (0x000055c6bc494000)
    
    # ls -ld /lib /lib/x86_64-linux-gnu /lib64
    drwxr-xr-x 26 root root  4096 May 15 07:41 /lib
    drwxr-xr-x  2 root root  4096 May 14 15:52 /lib64
    drwxr-xr-x  3 root root 16384 May 27 21:39 /lib/x86_64-linux-gnu
    
    # ls -l /lib/x86_64-linux-gnu/libtinfo.so.5 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
    lrwxrwxrwx 1 root root 32 Apr 14 23:16 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so
    lrwxrwxrwx 1 root root 12 Apr 14 23:16 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so
    lrwxrwxrwx 1 root root 13 Apr 14 23:16 /lib/x86_64-linux-gnu/libdl.so.2 -> libdl-2.23.so
    lrwxrwxrwx 1 root root 15 Feb 19 09:23 /lib/x86_64-linux-gnu/libtinfo.so.5 -> libtinfo.so.5.9
    

    They are just links we need to verify the target files

    # ls -lH /lib/x86_64-linux-gnu/libtinfo.so.5 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
    ##or
    # ls -lL /lib/x86_64-linux-gnu/libtinfo.so.5 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
    -rwxr-xr-x 1 root root  162632 Apr 14 23:16 /lib64/ld-linux-x86-64.so.2
    -rwxr-xr-x 1 root root 1864888 Apr 14 23:16 /lib/x86_64-linux-gnu/libc.so.6
    -rw-r--r-- 1 root root   14608 Apr 14 23:16 /lib/x86_64-linux-gnu/libdl.so.2
    -rw-r--r-- 1 root root  167240 Feb 19 09:23 /lib/x86_64-linux-gnu/libtinfo.so.5
    
1
  • 1
    if operating within a foreign architecture chroot - additionally check the permissions of the emulator you are utilizing in order to run its binaries, e.g ls -ld qemu-arm-static
    – anx
    Jun 1, 2016 at 10:42
4

You probably have a problem with permissions of files inside /lib (or /lib64) and/or files inside /dev.

Check that they belong to root and that at least some of the files inside de lib dir are executable by all users. Try to compare with a "clean" OS to verify which ones need to be executable by all.

You may check permissions and owner for files doing ls -l /lib, for example.

Ref link : http://www.tldp.org/LDP/LG/issue52/okopnik.html

2
  • 1
    Welcome to Askubuntu, thanx for your answer. I think you could improve your answer if you could also include some directions how to check the permissions.
    – Wouter
    Jan 14, 2014 at 16:54
  • Thank you so much. Permissions aren't the only thing that can break in fact. ABI is important too, and the right mismatch can similarly lead to this clueless error. For.. reasons, I found myself having a completely normal 2.27 glibc but with a rogue additional ld-2.30.so file in the lib folder. And funnily enough not even reinstall was helping, because any time it ran ldconfig that was symlinking ld-linux-x86-64.so.2 to the last versioned file it could see.
    – mirh
    Jan 8, 2020 at 19:25
3

just to let anybody know, I had the same problem with this error message and the solution for me was:

chmod 755 /

I mistakingly tried to change file permissions of all hidden "dot" files in a folder one level below the root folder which changed the permission of / from 755 to 750 Problem was:

cd /data; chmod o-rwx .*

0
0

Had a similar problem and the issue was an extra entry in a /etc/passwd for a single user. This happened after some changes to our ldap login server process, so it was probably just been mistyped entry. Figured it might help others so I should at least mention it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .