Cannot remove file: "Structure needs cleaning"

Question

I have an external hard drive which is encrypted via LUKS. It contains an ext4 fs.

I just got an error from rsync for a file which is located on this drive:

rsync: readlink_stat("/home/some/dir/items.json") failed: Structure needs cleaning (117)

If I try to delete the file I get the same error:

rm /home/some/dir/items.json
rm: cannot remove ‘//home/some/dir/items.json’: Structure needs cleaning

Does anyone know what I can do to remove the file and fix related issues with the drive/fs (if there are any)?

Solution 1

That is strongly indicative of file-system corruption. You should unmount, make a sector-level backup of your disk, and then run e2fsck to see what is up. If there is major corruption, you may later be happy that you did a sector-level backup before letting e2fsck tamper with the data.

Solution 2

If it helps anyone, I had a similar issue (rsync/rsnapshot backups, on an affected file). I posted my problem/solution, here:

https://ubuntuforums.org/showthread.php?t=2348768&p=13627299#post13627299

SUMMARY:

rsnapshot (rsync) backup error on arch linux x86_64 system; a corrupted, deeply-nested file was throwing that error, also shown when I tried to delete that file:

sudo rm -fR hourly.5/

rm: cannot remove 'hourly.5/snapshot_root/mnt/Vancouver/temp/temp - old/temp - 09 (Dec 07, 2014 - Sep 02, 2015)/a_OLD-gmail/[email protected]/[Gmail]/LINUX/rsync, rsnapshot; Other backups/19.bak': Structure needs cleaning

Here is the problem:

cd mnt/Vancouver/temp/temp\ -\ old/temp\ -\ 09\ \(Dec\ 07\,\ 2014\ -\ Sep\ 02\,\ 2015\)/a_OLD-gmail/[email protected]/\[Gmail\]/LINUX/rsync\,\ rsnapshot\;\ Other\ backups/

ls -l

ls: cannot access '19.bak': Structure needs cleaning
total 0
-????????? ? ? ? ?  ? 19.bak        ## << THAT IS THE PROBLEM!!

[ See also: https://www.reddit.com/r/linuxquestions/comments/4b47r2/has_anyone_ever_gotten_structure_needs_cleaning/ ]

My backup drive is /dev/sda1.

sudo umount /dev/sda1

sudo fsck.ext4 /dev/sda1  ## << accepted suggested fixes

Rebooted: all seems fine. Went into backups drive, deleted that problematic file:

/mnt/Backups/rsnapshot_backups/hourly.5/snapshot_root/mnt/Vancouver/temp/temp - old/temp - 09 (Dec 07, 2014 - Sep 02, 2015)/a_OLD-gmail/[email protected]/[Gmail]/LINUX/rsync, rsnapshot; Other backups/19.bak

Q.E.D.?!

[Update: yes; that worked: my backups are running normally, again! :-) ]

Solution 3

File systems sometimes are not in order and need cleaning. This can be done by fsck command. But remember, you must run fsck only to unmounted partitions to avoid risk of file corruption.

If your file system is ext4, try running this command :

fsck -AR -t ext4 -y

Solution 4

I fixed this problem with this command in my proxmox shell:

• stop the container

  pct stop 100
  

• fsck container, this repair the problem, on some issues files that are corrupt on container system

  pct fsck 100
  

• start the container

  pct start 100
  

Now backup and all is good!

Solution 5

I got the same error message from rsync and same error message from rm when I tried to delete the file. Because the filesystem was the root filesystem there was no way to use fsck. But when I just rebooted the system the file was gone and the backup succeeded. I have no clue why this worked but at least that's an easy fix and it's worth to try a reboot first.

View more solutions

Comments

[Rotareti]

Did what you suggested. e2fsck fixed some fs errors. Seems like I'm back to normal. Thx =)

[mrc02_kr]

It's not a solution: it's LUKS drive encrypted with LUKS. Accessing (or at least trying access) it from Windows is in my opinion not the best idea.

[G-Man Says 'Reinstate Monica']

So your answer is — stop any software that might be using the disk, run fsck, and resume using the disk.   How does this differ from DepressedDaniel's answer?

[higuita]

a list of what options do is always welcome, as we should teach people to understand what they are running instead of just copy/paste some magic command. So -A is check all fstab devices, -R will exclude the root filesystem from -A, as it is mounted readwrite and usually can't be check at this time (can be check offline or if mounted read-only) , -t ext4 to limit the list to ext4 filesystems (ignoring the others that may exist) and -y to auto-answer yes to the repair questions

[higuita]

Thjis is very different because it is a special case of proxmox containers. You can't fsck inside the lxc container nor have (a easy) direct control of the lxc devices to run the fsck, so this commands are the correct and easier answer for errors in a proxmox lxc container

[uz7]

@higuita This question is about “an external hard drive”, not an LXC device.

[higuita]

@Melebius you are correct for the question but i was referring to this specific answer. While this answer do not solves the original question, it is a useful answer for the same problem in a proxmox container. It is useful for people that arrive here via search (like me)

[Admin]

It worked because your filesystem was flagged for fsck at reboot.