I had similar issues before but i don't remember how i solved it.

When i try to copy something to USB stick, with FAT, it stops near the end, sometimes at 100%. And of course, when i transfer the memory stick somewhere else, it doesn't contain complete file. (file is a movie!)

I tried to mount device with mount -o flush, but i get same issue.

Also, i did format the USB stick with new FAT partition...

Any idea what cold i do?

p.s. I believe it's not related to OS, which is Debian, and i believe that coping from SSD drive doesn't make it stuck.

  • 3
    Somewhere I have met the following the matter explanation. In the case copying was made via operating memory, and idicator shows the process of reading data from drive. But wrighting process is much longer especially to USB-stick ( it can be 100 times slowly: like 2Mb/sec wrighting against 200Mb/sec of reading for example) and more over if you use no-native file systems like FAT or NTFS under linux. So try to wait for end transaction even if stopped on 100% but don't closed (which should indicate finish).
    – Costas
    Commented Jan 24, 2015 at 14:53
  • just wondering if it is possible at all to check the progress in that situation???
    – user27938
    Commented Jan 24, 2015 at 19:34
  • try to format pendrive with option overwrite exiting data with zeros It works on My trancend 8GB pendrive Commented Jul 6, 2017 at 7:37
  • 1
    For anyone coming across this issue, just format your drive to NTFS. Commented Jan 4, 2019 at 10:02
  • I experienced very low copy speed to a usb stick formatted as FAT32 and as EXT4. It was solved by formatting it to NTFS Commented Feb 7, 2021 at 19:30

3 Answers 3


The reason it happens that way is that the program says "write this data" and the linux kernel copies it into a memory buffer that is queued to go to disk, and then says "ok, done". So the program thinks it has copied everything. Then the program closes the file, but suddenly the kernel makes it wait while that buffer is pushed out to disk.

So, unfortunately the program can't tell you how long it will take to flush the buffer because it doesn't know.

If you want to try some power-user tricks, you can reduce the size of the buffer that Linux uses by setting the kernel parameter vm.dirty_bytes to something like 15000000 (15 MB). This means the application can't get more than 15MB ahead of its actual progress. (You can change kernel parameters on the fly with sudo sysctl vm.dirty_bytes=15000000 but making them stay across a reboot requires changing a config file like /etc/sysctl.conf which might be specific to your distro.)

A side effect is that your computer might have lower data-writing throughput with this setting, but on the whole, I find it helpful to see that a program is running a long time while it writes lots of data vs. the confusion of having a program appear to be done with its job but the system lagging badly as the kernel does the actual work. Setting dirty_bytes to a reasonably small value can also help prevent your system from becoming unresponsive when you're low on free memory and run a program that suddenly writes lots of data.

But, don't set it too small! I use 15MB as a rough estimate that the kernel can flush the buffer to a normal hard drive in 1/4 of a second or less. It keeps my system from feeling "laggy".

  • I was looking for a fix to this problem for a year or more, I thought it was just a bug in the linux. Thanks a lot.
    – Sidahmed
    Commented Jan 13, 2017 at 12:50
  • 2
    Linux noob here, could someone post how to change the <dirty_bytes> values?
    – Brofessor
    Commented Jun 15, 2018 at 9:21
  • 2
    This is similar to unix.stackexchange.com/questions/107703/… --- should have been fixed, but believe me, it's not. I had to add it to Ubuntu 18.04 to stop behaving funny...
    – Rmano
    Commented Nov 9, 2018 at 19:09
  • 2
    Works on Fedora 30 too. I am surprised to see such stupid behaviour even in modern Linux distros.
    – sziraqui
    Commented Sep 9, 2019 at 12:32
  • 1
    Anyone interested in developing a complete solution I've made some exploration here: github.com/RomuloPBenedetti/SaneFileTransfere it is a crude investigation for this problem in particular. Commented May 10, 2021 at 22:20

Late to the party, but a workaround I use to copy big files to USB stick is rsync.

The basic syntax I always successfully use is the following:

rsync -avh /home/user/Documents /media/user/myusbstick

Warning: if you want to copy the whole Documents folder use the syntax is ok. But if you want to copy only the file and not the folder you have to add a slash. Like this:

rsync -avh /home/user/Documents/ /media/user/myusbstick

Of course if you want to copy a file:

rsync -avh /home/user/Documents/file1 /media/user/myusbstick

for multiple files

rsync -avh /home/user/Documents/file1 /home/user/Documents/file2 /media/user/myusbstick

The syntax works for any folder/file you want to copy.

I'm aware this is not the real solution, but it's an easy and safe way to avoid annoying issues.

  • 3
    Welcome to the site, and thank you for your contribution. You may want to suggest the --progress option to have a rough equivalent of the progress bar found on graphical tools.
    – AdminBee
    Commented Sep 10, 2020 at 14:42
  • fyi: might not be a solution. I also use rsync and still have the problem of it stopping at literally 100% .. then took 5-10 minutes, same as the behavior described with GUI file-copy approaches. Commented Aug 10, 2023 at 6:49

Old question, but it seems as though the problem still comes up. Setting the buffer to 15MB as suggested here did not work on Ubuntu 19.04, and brought my system to a grinding halt.

I was trying to copy a 1.5GB file onto an empty (newly formatted) FAT32 16GB drive. I let it run for about 10 minutes just to see if it would finish, with no luck.

Reformatting to NTFS let the operation finish in less than 10 seconds. I don't know why this would matter because FAT32 should allow any single file with size under 4GB, but it seemed to work just fine. Not an ideal fix for drives you want to use with MacOS, but an easy workaround for all other use cases. I imagine exFAT would have worked similarly, but I did not test it.

  • 1
    Same problem with 19.10 and exFAT drive. Unable to copy a 40GB VMDisk over USB3Gen2 to an M.2 drive (Always fails using nautilus even cp/rsync). System is a 3950x 64gb of memory so not short on resources. Have to copy to a network drive (centos box) then mount my usb drive to my network server. This problem has been following Ubuntu like a dog with flees
    – John
    Commented Apr 7, 2020 at 18:21
  • curious, the quick and dirty change to NTFS is at least giving me an indication tha the files are moving, and its much faster than FAT32. wonder what ext4 would do?
    – Paul TIKI
    Commented Aug 8, 2020 at 6:31
  • I have seen this problem mentioned across forums that deal with various Debian flavors, the only apparent solution is disabling sync as a mount option
    – endrias
    Commented Apr 29, 2021 at 13:36
  • This is 2021, I'm using ubuntu 20.04 and still it's impossible to copy a 1 gigabyte file to a usb key. This is crazy.
    – gianni
    Commented Sep 5, 2021 at 21:56
  • Same problem in 2022, Ubuntu 20.04, try and copy a 350MB file to a FAT usb, takes almost a minute. Format to NTFS and is done in a few seconds...
    – Devyzr
    Commented Feb 17, 2022 at 15:23

You must log in to answer this question.