Quota used in nowhere?

themadyc · 06-06-2010, 01:40 AM

I have a problem with quota on shell account. When I type quota -s to see used space, it shows me blocks - 2130M. However, when i type du -sh in my home folder, it shows me that i have used 985M. It has been for a couple of months now.

Where could the non-existing 1.1GB be?
I suspect, it might have something to do with rtorrent or apache, because some time ago I was downloading some Linux distros on shell via rtorrent, and then downloaded it on my local PC's via http. Files where in ~/public_html. It might be possible, that I have accidentally removed files, while they were still in use.

I don't have root access.

colucix · 06-06-2010, 05:25 AM

Hi and welcome to LinuxQuestions.

The command quota -s does not necessarily report the total size of files in user's HOME directory, but all the files owned by the user and spread to the filesystem where quotas are applied. Is there a chance you have some files, owned by you, in places other than your HOME dir? Here is a command to find out:

Code:

find /home -wholename $HOME -prune -o -user username -print 2> /dev/null

where /home has to be the actual mount point of the filesystem that contains user's home dirs and username must be your actual user name.

themadyc · 06-07-2010, 12:52 AM

Thanks for your reply.

Could you tell my why are you directing the output to /dev/null? When I remove >/dev/null to see the actual output, it shows me:

Code:

find: invalid argument `themadyc' to `-user'

I used sth like this (/home/themadyc is my homedir):

Code:

find /home -wholename $HOME -prune -o -user themadyc -print 2

I did some digging, and I noticed, that on this shell, user also has permissions to write to folders like /var/tmp, however, I don't have permissions to do sth like this: ls /

Is there any apache (or maybe rtorrent?) cache for files that are being downloaded?

colucix · 06-07-2010, 02:59 AM

Quote:

Originally Posted by themadyc

Could you tell my why are you directing the output to /dev/null? When I remove >/dev/null to see the actual output, it shows me:

Actually I redirected only the standard error to /dev/null:

Code:

2> /dev/null

to avoid error messages coming up when find tries to enter directories for which your user hasn't got permissions. Most likely they would have hidden (scroll up) the actual results of the find command.

Anyway you got an unexpected error. Is themadyc your actual user name? Eventually you can try with the numeric ID. You may check them both using the command:

Code:

id

Regarding cache files I don't know exactly but I guess they would be stored in your home directory or in /tmp. Maybe I should have asked before, but... what is the partition with quotas? Is it /home (does it exist) or is it the entire directory tree?

themadyc · 06-08-2010, 12:23 AM

Well, accualy I am not sure what is the partition in with quotas. I can only guess that it is / because for example when I have written sth to /var/tmp, it also uses quota.

id:

Code:

uid=1463(themadyc) gid=1030(elite),groups=1016(grsec),1023(donor),1030(elite),1243(users)

so i guess it should be:

Code:

find /home -wholename $HOME -prune -o -uid 1463 -print 2

however i get:

Code:

find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

and by the way:

Code:

# find /
/
find: /: Permission denied
# find /home
find: /: Permission denied

colucix · 06-08-2010, 02:49 AM

It looks like user themadyc does not have permission to read root directory. Anyway, the mount command (without arguments) should tell you which filesystems (partitions) have quotas. The df command also should tell you about the partition layout, in particular to see if /home is in its own partition.

Regarding the find command-line, please re-read my previous posts. You will find out that the final 2 was indeed part of the redirection of standard error to /dev/null and it should not be there at the end of the command:

Code:

find /home -wholename $HOME -prune -o -uid 1463 -print

or

Code:

find /home -wholename $HOME -prune -o -uid 1463 -print 2> /dev/null

should work now.

After that you can extend the search to all the directories where you have write permissions and where you suspect there are some files owned by themadyc that can increase user's quota. Anyway, since some time has passed since your first post, is the situation still the same? Does your user's quota still show such a discrepancy with the size of your home directory?

Edit: oops, sorry... I've just noticed from the very last line of your post, that you cannot even read /home directory. Maybe we should try another method. Anyway, finding out which is the partition layout and which partitions have quota applied should help.

Just a silly question: have you tried to ask the system administrator?

themadyc · 06-08-2010, 07:55 AM

I really appreciate your help, but i'm still having some permission trouble.

Code:

tma@host:~$ find /home -wholename $HOME -prune -o -uid 1463 -print
find: /: Permission denied
tma@host:~$ mount
-bash: mount: command not found
tma@host:~$ df
-bash: df: command not found

The problem started in 2009 and still exists...

I've try contacting him - he didn't know whats going on. I got a few additional quota space, but it's not a solution.

I've also noticed something strange. I cannot access for example /var, but i can access /var/tmp - when i write there the same quota is used.
Are there any more tmp folders besides /var/tmp or /tmp that i might have access to?

colucix · 06-08-2010, 11:16 AM

It looks like you're running a restricted shell, since you don't have some basic commands at your disposal. Anyway, what if you look for files owned by themadyc in the tmp directories?

Code:

find /tmp /var/tmp -uid 1463 -type f -printf "%k\t%p\n"

this will print out the 1k-block size along with the filename.

Quote:

Are there any more tmp folders besides /var/tmp or /tmp that i might have access to?

Nope. Usually there are only these two. However if the quota is applied to /var, you may check also the /var/spool directory that stores, among other things, the user's mail.

Regarding your first guess, it's true that if you remove a file while in use, the disk space is not really freed. But this is true until the process that keep it open has not finished. Therefore, I doubt such a situation is the reason of 1.1 Gb of "ghost" disk space!

Please, let me know about the results of the command above (hope it works).

themadyc · 06-08-2010, 12:42 PM

Unfortunately it still doesn't work. I don't have any access to /var/spool
As far as the find stuff is concerned it showed basically nothing.

If it important, I had to modify it so it would work. It didn't show anything besides some permission denied stuff.

Code:

cd /tmp && find . -uid 1463 -type f -printf "%k\t%p\n"

colucix · 06-09-2010, 03:04 AM

Well.. at this point I am a bit lost. If the problem is due to a badly configured user's quota, the issue should be addressed by the system administrator. Moreover, once you report the problem he/she could do all the proper checks, in particular the search for files owned by you, across all the filesystems where quota is applied. He/she should have the tools to manage the issue, not you as a regular (and restricted) user.

Anyway, just to have a clear view of what the problem could be, can you post the output of the commands quota -v and quota -g, please? Thx.

themadyc · 06-09-2010, 10:27 AM

Code:

tma@host:~$ quota -v
Disk quotas for user tma (uid 1463): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
      /dev/sda2 2038092  5242880 5672960            6025       0       0                                                                                                                                                                           tma@host:~$ quota -g

I don't think that there is any quota set for groups.

colucix · 06-10-2010, 10:03 AM

The only chance coming into my mind is that the quota block size could be different from 1024k. If it was 512k the quota usage nearly matches the output of the du command. Anyway, on the majority of linux systems the quota block size is 1024k, but only the system admin can tell for sure. Which system (Linux distribution or Unix flavor) is this, anyway?

themadyc · 06-11-2010, 12:11 AM

Well it's Debian

Code:

tma@host:~$ uname -a
Linux host 2.6.29.1-grsec #1 SMP Wed Apr 22 15:05:15 CEST 2009 i686 GNU/Linux

EDIT: if I download additional 1-2GB to my home dir, there is still 1,1GB missing. Do you still think it is block size fault?

I was thinking of doing rm -rf / but wouldn't it remove any important, not mine files?

arizonagroovejet · 06-13-2010, 05:36 AM

Don't run 'rm -rf /'. It wouldn't remove any files that you don't have write permission on, which shouldn't be any files that you don't own, but it would wipe out the contents of your home directory. Or at least I think it would. I'm not going to try it to find out.

I was going to say post the output of mount but you apparently don't have that. Erm... try

Code:

$ /bin/mount

Also, what's your PATH and shell

Code:

$ echo $PATH
$ echo $0

I have seen a couple of users with this problem as part of my job. I'm surprised your system administrator hasn't been able to sort it out.

If your home directory is mounted from a remote server, i.e. you are logged in to machine A whilst your home directory resides on server FOO, then looking in /tmp and /var/tmp or anywhere on the local disk of machine A isn't going to help you as they won't contributing to your quota.

One possibility is that the system has lost track of your quota usage and is reporting it incorrectly. I've known that happen occasionally on the Solaris boxes that are used for home directories where I work. I don't know why it happens, I don't administer them, but those who do have told me that's the cause of a user's problem on a couple of occasions.

colucix · 06-13-2010, 08:46 AM

Thank you, arizonagroovejet for helping. I totally agree. The system administrator should have the competence and the tools to find out what's happening here. I am surprised too.

@themadyc: sorry I did not see you edited the last post, otherwise I would have given the same answer: don't do that. rm -rf / is a command that every *nix user should forget or eventually remember to never type it and press enter. Indeed it would wipe out your entire home directory (actually it would leave an empty /home/themadyc).

Furthermore the rm command cannot find anything different than the files you have access to (using ls or find).

Given the result of your last test, the block size problem is a non-sense. On the contrary, now that arizonagroovejet mentioned it (the system has lost track of your quota usage), I remember the same problem when I was working on Sun Solaris systems. In that case the system administrator run the quotacheck command to update and eventually adjust the quota database.

Good luck!