Quota used in nowhere?
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. |
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 |
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' Code:
find /home -wholename $HOME -prune -o -user themadyc -print 2 Is there any apache (or maybe rtorrent?) cache for files that are being downloaded? |
Quote:
Code:
2> /dev/null 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 |
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) Code:
find /home -wholename $HOME -prune -o -uid 1463 -print 2 Code:
find: paths must precede expression Code:
# find / |
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 Code:
find /home -wholename $HOME -prune -o -uid 1463 -print 2> /dev/null 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? |
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 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? |
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" Quote:
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). :) |
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" |
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. |
Code:
tma@host:~$ quota -v |
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?
|
Well it's Debian
Code:
tma@host:~$ uname -a I was thinking of doing rm -rf / but wouldn't it remove any important, not mine files? |
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 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. |
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! :) |
All times are GMT -5. The time now is 01:50 PM. |