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)?


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.

  • Did what you suggested. e2fsck fixed some fs errors. Seems like I'm back to normal. Thx =) – Rotareti Dec 20 '16 at 20:06
  • I strongly suggest people to use GUIs like e.g. gparted to do this. Gparted still wraps e2fsck (in the case of checking a partition), but the graphical interface makes it a lot easier to select the proper hard-disk, as well as ensuring that you run these tools with the correct arguments. With the wrong arguments you risk severe loss of data! – Qqwy Feb 7 '19 at 22:50

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



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/victoria.a.stuart@gmail.com/[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/victoria.a.stuart@gmail.com/\[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/victoria.a.stuart@gmail.com/[Gmail]/LINUX/rsync, rsnapshot; Other backups/19.bak


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


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

It's usual error when try remove .Trash-0 if you try remove windows in encoding CP1251 file system on Linux system. So fs is corrupt but this dosn't metter. Fs of Windows always corrupt as see from Linux. But is not so. You may try open this file from windows os All will be well. And then remove it in windows. And only after that clean trash.

  • 1
    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. – mrc02_kr Oct 23 '18 at 8:08

all!! i fix this problem with this command in my proxmox shell

pct stop 100 ## stop the container

pct fsck 100 ## fsck container, this repair the problem, on some issues files that are corrupt on container system

pct start 100 ## start the container , ok, now backup and all is good!!

Thanks all, Chuck

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.