Pivotal Knowledge Base


Unix server treats the login with message "-bash: /dev/null: Permission denied"


Connecting to the Unix box via the user (i.e say gpadmin) errors out with the below message

[root@xxx ~]# su - gpadmin
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied

This indicates the bash that is needed to set the profile is not working, which also yields to the problem of not setting the environment (defined at .bash_profile or .profile ) after you connect.

Since the environment is not set , the gpssh / gpstate or other greenplum utility would now fail with messages for eg.s like this.

[gpadmin@xxx ~]$ gpstate
sh: /dev/null: Permission denied
20150210:09:46:59:013478 gpstate:ric00slm0001:gpadmin-[INFO]:-Starting gpstate with args:
20150210:09:46:59:013478 gpstate:ric00slm0001:gpadmin-[CRITICAL]:-gpstate failed. (Reason='[Errno 2] No such file or directory: '/postgresql.conf'') exiting...


The cause is due to the corrupted /dev/null file, the corruption can be caused may be due some one modified the file or some one did some alteration to the /dev/null or moved something to the /dev/null which corrupted the file

[root@ric00slm0001 gpadmin]# ls -ltr /dev/null
crw-rw-r-- 1 root utmp 1, 3 Feb  9 08:23 /dev/null


Restart the server and this should fix the problem


The permission of the /dev/null should be 666 , if for some reason its not 666 then change the permission using

[root@xxx gpadmin]# chmod 666 /dev/null


if after changing the permission, the issue still exists then remove and recreate the NULL file

[root@xxx gpadmin]# rm /dev/null 
[root@xxx gpadmin]# mknod -m 666 /dev/null c 1 3
[root@xxx gpadmin]# ls -ltr /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 10 10:03 /dev/null
[root@xxx gpadmin]# chown root:utmp /dev/null

Even after the changes mentioned above, the /dev/null is still being modified would request to enable the audit on /dev/null as indicated on the redhat knowledge base



Powered by Zendesk