[Solved] Not able to delete/create file in /tmp

UNIX AIX
1

This is AIX box and I am not able to create or delete file in /tmp though space is there

root@ttcols01/ #touch /tmp/test_file
touch: 0652-046 Cannot create /tmp/test_file.
root@ttcols01/ #mkdir /tmp/test_dir
mkdir: 0653-358 Cannot create /tmp/test_dir.
/tmp/test_dir: Invalid file system control data detected.
root@ttcols01/ #id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp),203(avdefs)
root@ttcols01/ #ls -ld /tmp
drwxrwxrwt   28 bin      bin            8192 Jan 18 04:30 /tmp
root@ttcols01/ #mount  | grep tmp
         /dev/hd3         /tmp             jfs2   Sep 26 14:26 rw,log=/dev/hd8
root@ttcols01/ #
2

Possible hardware issue. What does the errpt report show. What does lsvg -p rootvg show? What about other file systems? What does fsck /tmp show?

3

I can create/edit files in /, opt and var. It is only /tmp where I am getting this error

root@ttcols01/ #errpt
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
BFE4C025   1119195913 P H sysplanar0     UNDETERMINED ERROR
root@ttcols01/ #lsvg -p rootvg
rootvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk0            active            558         512         111..91..87..111..112
4

Hello,

If you are getting like IO error as well as you are not able to delete or create files in /tmp then there is a chance that it would have become read only. If this is the case then reboot should work.

NOTE: Don't reboot server before confirmation.

Thanks,
R. Singh

5 
#mount | grep tmp
         /dev/hd3         /tmp             jfs2   Sep 26 14:26 rw,log=/dev/hd8

I can see, it is mounted it rw

6

You gave the answer yourself already:

Your filesystem is damaged, unmount and repair it (via "fsck"). As "/tmp" is supposed to hold no vital data anyway you could also recreate (=format) it.

I hope this helps.

bakunin

1 Like
7

I will arrange for the downtime and will fix as suggeted. Thanks

8

FYI

http://www-01.ibm.com/support/docview.wss?uid=isg3T1000131
1 Like
9

This is interesting information, but i do not think it is necessary to carry out in this case. As the root FS is not affected one can simply unmount /tmp and recreate it. It will suffice to select some time with minimal system activity.

See above. I do not think you need a downtime at all.

I hope this helps.

bakunin

10

Yes, I am able to unmounts /tmp (after killing cron and snmp daemon which were using /tmp). Ran fsck and mounted it back. It is all good not, without downtime.
Your suggestion helped. Thanks