2

I'm working on a file system where I don't have root permissions and all of the above have failed to allow me to delete a file with the same errors:

$ >file1
$ -bash: file1: Disk quota exceeded

$ dd count=1 if=/dev/random of=file1
$ dd: opening `file1': Disk quota exceeded

$ rm file1
$ rm: cannot remove 'file1': Disk quota exceeded

$ cat /dev/null > file1
$ -bash: file1: Disk quota exceeded

Also tried this on a buch of files:

$ mv file1 f
$ mv: cannot move `file1` to `f`: Disk quota exceeded

edit have now also tried:

$ cp /dev/null file1
$ cp: cannot create regular file 'file1': Disk quota exceeded

to no avail (same error msg received)

there are a lot of other files I that just give me a permission denied error but I think for some of those it's because I don't have root permissions. Anyways, there are plenty of files for which I do have write permissions so I really just need a way to force those files to be erased. Is there any workaround I can use?

Output of df -s for this filesystem: 

Filesystem            Size  Used Avail Use% Mounted on
zfs1.local:/volatile  699G  699G     0 100% /nfs/volatile
Improve this question
10
  • It won't even let you open the file because the disk quota is exceeded? Wow. That looks like a broken filesystem. From what I can tell, your entire mount is basically read-only now. You'll have to ask the relevant system administrator to remove at least one large file for you, or temporarily relieve your quota.
    – allquixotic
    Commented Sep 27, 2014 at 13:40
  • @allquixotic That's exactly what I'm afraid of :/ But I think you're right
    – kjh
    Commented Sep 27, 2014 at 13:44
  • Can you rename (mv) any files? If so, try renaming a bunch of files to single-character names. That might free up enough space in the metadata blocks to let you rm a file. If you have enough long file names, you should be able to free up a kilobyte or more. Not sure how much you need free to be able to truncate or delete a file, but it should get you somewhere.
    – allquixotic
    Commented Sep 27, 2014 at 13:44
  • I tried that in desperation a few hours ago thinking I was clever but sadly it failed as well with the same error.
    – kjh
    Commented Sep 27, 2014 at 13:46
  • What filesystem is this, by the way? Do you know? It may be a bug in the filesystem itself that it has to use space to do anything. The answer that Cyrus posted REALLY should have worked, since ZFS is copy on write, and even ZFS allows that to work.
    – allquixotic
    Commented Sep 27, 2014 at 13:47

2 Answers 2

Reset to default
1

In my case, none of the above worked when the quota was 100% full. Fortunately the /tmp was not full so I did:

rsync --remove-source-files -azv file1 /tmp

and it solved the problem.

Improve this answer
0

I have recovered the system using the command 'wipe'. Execute wipe on some big file and then try to use the command 'rm'. it will work.

Improve this answer
2
  • 1
    Can you elaborate at all- why would wipe work when rm wouldn't?
    – bertieb
    Commented Apr 27, 2017 at 10:25
  • As allquixotic commented in the question, ZFS is a copy-on-write filesystem, so a file deletion actually needs slightly more space on disk before a file is deleted. It has to write the metadata before it remove a file, whereas the command wipe actually removes the file content in the way it cannot be recovered. It does not requires extra space in disk. So the condition "Disk quota exceeded" will not affect wipe.
    – johny
    Commented May 2, 2017 at 6:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .