I ran into this problem when copying a lot of files using tar -cf - * | (cd ../bar; tar -xf - );.

I did search on the issue, and found the below suggestions, none of which worked for me. This problem persists even after reboot.

One peculiarity of the issue is that the destination disk was just a data disk in NTFS, as I'm using a dual boot (ubuntu 20.04 and Windows 10). So, I tried to fix it using chkdsk in Windows 10 (see #6 below), but it didn't help much. I cannot copy a file into the disk when booted in Windows 10 either, but see a different message saying, "too much fragmented", so I tried to defragment the disk using the Windows tool, but the optimization didn't proceed. I don't think "too fragemented" is the real issue, as only 2T is used out of 15T space, and the disk is just two months old.

Could someone please advise me on what could be further tried? Thanks a lot for your expertise in advance!

EDIT: In running tar -cf - * | (cd ../bar; tar -xf - );, I guess some overflow happened, which may have corrupted something critical. It might be related to some environment parameter in Ubuntu 20.04, but understanding what could be corrupted and why that happened is beyond my understanding of Linux / Ubuntu

  1. check the disk space <- plenty of space is available (the problematic disk is /mnt/e, the second one from the end) df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            252G     0  252G   0% /dev
tmpfs            51G   32M   51G   1% /run
/dev/nvme0n1p2  1.8T  828G  912G  48% /
tmpfs           252G   15M  252G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           252G     0  252G   0% /sys/fs/cgroup
/dev/loop0      128K  128K     0 100% /snap/bare/5
/dev/loop1       56M   56M     0 100% /snap/core18/2246
/dev/loop2       62M   62M     0 100% /snap/core20/1169
/dev/loop3      219M  219M     0 100% /snap/gnome-3-34-1804/72
/dev/loop5       56M   56M     0 100% /snap/core18/2128
/dev/loop4       66M   66M     0 100% /snap/gtk-common-themes/1519
/dev/loop6      9.5M  9.5M     0 100% /snap/htop/3233
/dev/nvme0n1p1  511M  5.3M  506M   2% /boot/efi
/dev/nvme1n1p3  1.9T  1.2T  665G  65% /mnt/c
/dev/loop7       33M   33M     0 100% /snap/snapd/13640
/dev/loop8       51M   51M     0 100% /snap/snap-store/547
/dev/loop9       33M   33M     0 100% /snap/snapd/13270
/dev/loop10      66M   66M     0 100% /snap/gtk-common-themes/1515
tmpfs            51G   16K   51G   1% /run/user/125
/dev/sda2        15T   12T  3.3T  78% /mnt/z
/dev/sdb2        15T  2.0T   13T  14% /mnt/e
tmpfs            51G   36K   51G   1% /run/user/1000
  1. usage of inodes <- 1% is used in /mnt/e, df -i
Filesystem          Inodes    IUsed       IFree IUse% Mounted on
udev              65989773     1100    65988673    1% /dev
tmpfs             65997179     8821    65988358    1% /run
/dev/nvme0n1p2   122068992  1554395   120514597    2% /
tmpfs             65997179       40    65997139    1% /dev/shm
tmpfs             65997179        5    65997174    1% /run/lock
tmpfs             65997179       18    65997161    1% /sys/fs/cgroup
/dev/loop0              29       29           0  100% /snap/bare/5
/dev/loop1           10833    10833           0  100% /snap/core18/2246
/dev/loop2           11732    11732           0  100% /snap/core20/1169
/dev/loop3           18500    18500           0  100% /snap/gnome-3-34-1804/72
/dev/loop5           10803    10803           0  100% /snap/core18/2128
/dev/loop4           65095    65095           0  100% /snap/gtk-common-themes/1519
/dev/loop6            3605     3605           0  100% /snap/htop/3233
/dev/nvme0n1p1           0        0           0     - /boot/efi
/dev/nvme1n1p3   698250164  1718509   696531655    1% /mnt/c
/dev/loop7             479      479           0  100% /snap/snapd/13640
/dev/loop8           15841    15841           0  100% /snap/snap-store/547
/dev/loop9             474      474           0  100% /snap/snapd/13270
/dev/loop10          64986    64986           0  100% /snap/gtk-common-themes/1515
tmpfs             65997179       45    65997134    1% /run/user/125
/dev/sda2       3505524112    20634  3505503478    1% /mnt/z
/dev/sdb2      13549630048  3278197 13546351851    1% /mnt/e
tmpfs             65997179       94    65997085    1% /run/user/1000
  1. disk/file permission issue <- not an issue

  2. increasing inotify.max_user_watches. It was 65536 and increased to 524288, but didn't help

  3. check the sizes returned by du -h and df -h. Both are the same

  4. the disk could have been damaged <- Windows chkdsk found one unrelated file orphaned, which was fixed. On the second chkdsk run, no issue was found in Windows, chkdsk E: /f

Stage 2: Examining file name linkage ... 
Deleted invalid filename Refinitiv\References (2BE9F9) in directory 5.
File 2BE9F9 has been orphaned since all its filenames were invalid
Windows will recover the file in the orphan recovery phase.
Correcting minor file name errors in file 2BE9F9.
Deleting index entry Refinitiv\References in index $I30 of file 5.
  6 reparse records processed.
  3630180 index entries processed.
Index verification completed.
 Phase duration (Index verification): 14.18 minutes.
CHKDSK is scanning unindexed files for reconnect to their original directory.
  1 unindexed files scanned.
  0 unindexed files recovered to original directory.
 Phase duration (Orphan reconnection): 0.00 milliseconds.
CHKDSK is recovering remaining unindexed files.
  1 unindexed files recovered to lost and found.
    Lost and found is located at \found.000
 Phase duration (Orphan recovery to lost and found): 0.00 milliseconds.
  6 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 8.49 milliseconds.
  1. lsof/ | grep "deleted" --> no such file or directory with the below warning
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/125/gvfs Output information may be incomplete. 
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing Output information may be incomplete.

1 Answer 1


I cannot copy a file into the disk when booted in Windows 10 either,

This would suggest your target filesystem is sufficiently broken that not even Windows can use it. If windows' disk checking can't repair it: good luck! You should probably all you can from /mnt/e to some backup medium, and use windows to format that volume.

  • Thanks Marcus for the comment. Yes, I'll format the disk. To prevent this failure again, should understand what caused this issue in running tar -cf - * | (cd ../bar; tar -xf - ); this tar command must have corrupted something critical, and why.
    – surfer21
    Nov 4, 2021 at 21:46
  • no, tjat command can't corrupt anything. It's just a userland program, not directly manipulating the file system. Anyways, that's a new question, and please don't ask such in the comments. Nov 4, 2021 at 22:57
  • I guess it may be related to some environment parameters in Ubuntu. No, this is not a new question. this is all about this posting, but let me add this part in the main part.
    – surfer21
    Nov 4, 2021 at 23:05
  • .... please don't add new questions to an existing question, but ask them as new questions. Nov 5, 2021 at 19:34
  • The command is unrelated as said, but consider using a simple cp or rsync. No need for such an overly complicated command. For example: cp -R * ../bar Nov 16, 2021 at 9:25

You must log in to answer this question.

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