Acutally I already tried that quota -v user and found that he has already exceeded his limit. Also I confirmed this on the filer as well using quota report directory.

The reason why I do not simply increase his quota, is because we do not allow users to create files beside his/her home dir. I need to find out why this is happening and fix it.

Thanks for your comment though.

Daniel Jung

I can think of several common scenarios where a user ends up owning files outside their home directory.

If superuser uses tar to "untar" an archive file, then tar preserves the original owner of the files. So let's suppose you download a big tar archive from some web site and the files in the archive are all owned by uid N. And then by coincidence you also have a user with uid N. When superuser un-tars the archive, this creates a whole lot of files owned by N.

Similar things can happen with other file archivers such as cpio, dump/restore, etc.

Also, if superuser uses tar or cpio or rsync or "cp -r -p" to copy files from one user's directory to another, the original file owner is preserved.

Perhaps superuser got careless with "chown -R" and inadvertently changed ownership of a bunch of files to the user. When you chown a file from one user to another, the disk space totals for both users are adjusted accordingly.

And finally, a user can open up any directory he owns with chmod 777. So if I open up one of my directories like this, then anyone else can create files in that directory, but they own them, not me. So their quota gets charged, not mine.

I suggest going to the top of the volume and running:

find . -user username -print

which will find all files owned by the user. Then you will be able to figure out what happened.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support

William W. Arnold writes:

Steve Losen writes ---

...

I can think of several common scenarios where a user ends up owning files outside their home directory.

[cut superuser scenarios] [cut mode 777 dir scenarios]

Another scenario that I've seen. If user B makes a hard link to a file owned by user A, in user B's directory, and then user A deletes his link to the file, then the file will continue to exist in user B's directory, owned by user A.

This happened a lot in my undergraduate college days, when we had really small quotas, and wanted to have lots of programs. One student would compile the program, and then lots of others would link to it, thereby avoiding the quota. Hard links were used instead of soft links, (or just setting the path) because when a user left the school, the admin's didn't go hunting the files down across the entire filesystem, they just removed the homedirs. There were files around that were owned by students that had left over 5 years earlier.

Sysadmins falling down on the job there, I think!

We do regular scans of the relevant directory trees for "wrong owner" files, and inform both parties of anomalies. We also have a policy that either user can ask for the misplaced files or directories to be removed in the case when they have insufficient access to do so themselves. Also "such requests will automatically be considered to have been made by any user whose account has been cancelled."

I have a Perl script "ownerchange" which identifies places in a directory tree where ownership changes between a directory and the thing contained in it. (Ideally applied to a NetApp snapshot to guarantee non-mutability during scanning and non-updating of atimes.) Let me know if it you think it might be useful.

Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.