Problem in assigning secondary group

[Ahmed Iftikhar]

Hi

I'm trying to assign secondary group to some of the users. Following is the error message it throws:

msgcnt 216 vxfs: mesg 001: vx_nospace - /dev/root file system full (1 block exte

nt)

Cannot modify /etc/group file, /etc/passwd was modified


I would like to assign secondary group group1 to user1. Following is the command I have used to do that:

usermod –G group1 user1


Also, for your information, I have logged in as root. Please let me know, how to resolve this issue.


Many thanks in advance
Ahmed Iftikhar

[Robert-Jan Goossens · Accepted solution]

Ahmed,

The error message speaks for itself.

/dev/root file system full

# bdf /

Is the root filesystem full ?

Best regards,
Robert-Jan

[Leif Halvarsson_2]

Hi,
Looks like the root filesystem is full. Do a "bdf" and see if / show 100%. If it is, you must find the reason why the filesystem has become full, normally there should be little activity on that filesystem. Try to find if there is some folders that not should be there and remove (or, move to a different location).

[Ahmed Iftikhar]

Thanks for your immediate response.

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 204800 0 100% /
/dev/vg00/lvol1 298928 39168 229864 15% /stand
/dev/vg00/lvol8 4710400 1757640 2929768 37% /var
/dev/vg00/lvol7 1499136 1076032 420344 72% /usr
/dev/vg00/lvol4 204800 8720 195240 4% /tmp
/dev/vg00/lvol9 614400 509818 98057 84% /ora
/dev/vg00/lvol6 1015808 899856 115088 89% /opt
/dev/vg00/lvol5 819200 335496 483704 41% /home
/dev/dsk/c1t2d0 540700 540700 0 100% /cdrom
/dev/vg00/ascl 11534336 3768581 7293794 34% /ascl
/dev/datavg/lvol1 35557376 674072 34610784 2% /data
/dev/indexvg/lvol1 35557376 525552 34758144 1% /index
/dev/systemvg/lvol1
35557376 6967080 28367192 20% /system
/dev/applvg/lvol1 35557376 15232368 20167488 43% /appl

It seems root filesystem is full, how to resolve this?

Best Regards
Ahmed.

[Pete Randall]

The most common cause is a typo when specifying a device file on a backup command so check under /dev for any regular files:

find /dev -type f

Also look for dumps:

find / -name core

Look for large files:

find / -size +10000


Pete

[Robert-Jan Goossens]

search for large files inside /

# find / -xdev -size +1000 -exec ll {} \;

could be someone made a tar mistake omn instead of 0mn.

Robert-Jan

[Leif Halvarsson_2]

Hi,
It is not possible to increase / without reinstalling the server (for example with ignite). You must, either remove some unnecessary files/folders or, move some folder to a different filesystem and create a link to the original location.

[Ahmed Iftikhar]

Can i go ahead and delete the core files which is more than 100000?

Thanks a lot to everyone for ur immediate responses.

[Robert-Jan Goossens]

First move the core files to /tmp.

You can examen them later.

[Pete Randall]

I would suggest /var/tmp instead of /tmp: there's a lot more room there.


Pete

[Ahmed Iftikhar]

After moving the core file, my problem got resolved. I was able to assign secondary group. But root file system seems to be still 100%.

[Bill Hassell]

It is really difficult to fix a full filesystem by looking for big files! Instead, look for big directories:

du -kx / | sort -rn | head -20

Post the result the above command and we can tell you where the problem is. A 'normal' root filesystem will show soemthing like this:

89208 /
41080 /etc
38448 /sbin
26680 /etc/vx
21656 /etc/vx/type
10160 /etc/opt

If you have other directories, ESPECIALLY /dev that are at the top of the list, these need to be examined--they are misplaced.

[Ahmed Iftikhar]

Bill, here is the output:

$ du -kx / | sort -rn | head -20
du: bad status < /etc/ftpd/ftp-exec >
du: bad status < /etc/ftpd/pids >
du: cannot open < /etc/sam/custom >
du: cannot open < /etc/opt/resmon/persistence >
du: cannot open < /etc/opt/resmon/pipe >
du: bad status < /dev/vx/dmpconfig >
du: bad status < /dev/vx/config >
du: bad status < /dev/vx/trace >
du: bad status < /dev/vx/iod >
du: bad status < /dev/vx/info >
du: bad status < /dev/vx/task >
du: bad status < /dev/vx/taskmon >
du: bad status < /dev/vx/clust >
du: bad status < /dev/vx/netiod >
du: cannot open < /.dt/Desktop >
198040 /
106192 /etc
53816 /interface
52936 /interface/comet
37216 /sbin
32312 /interface/comet/comet_dev_sk
31864 /interface/comet/comet_dev_sk/dsproject
26680 /etc/vx
21656 /etc/vx/type
14736 /etc/opt
8976 /etc/opt/resmon
8616 /etc/vx/type/static
6344 /etc/vx/type/gen
5880 /sbin/fs
5120 /etc/vx/type/raid5
4696 /etc/lvmconf
4008 /etc/vx/static.d
3832 /etc/opt/resmon/log
3568 /etc/opt/resmon/lbin
3512 /etc/opt/samba

[Bill Hassell]

The errors you see: du: bad status
are from directories that you are not allowed to read. To fix anything in the / directory, you'll need to become root first, then run the du command.

However, the first error is: /interface
That is a directory that has nothing to do with the OS and should be moved to another mountpoint. Since it looks like some sort of project directory, it could go into /var (perhaps create a /var/project directory). That will return almost 54megs freespace to the / directory.

It also looks like / may have a lot of loose files in it. Use this command:

ll / | grep ^- | sort -rnk5 | head -20

My guess is that you'll find a bunch of large files in /, probably because root's $HOME was never moved and all the root users have been dumping junk files in that location. And even some developers have been playing in that directory by putting scripts or code or worse: logfiles, into the / directory.

I would definitely move root's HOME directory from / (the worst possible location) to something like /home/root or possibly /root. Then move all the files (as reported by the ll | grep command above) to either root's new HOME or to more appropriate directories.