Linux Mint 18.2, MATE.

Cancelling of file operations via Caja takes a lot of time. For example, I was copying 20 files to the USB drive (11,5 GB on a whole) and then canceled it; it's been more than a hour, but the file operation hasn't been canceled and its windows hasn't been closed.

enter image description here

What can be wrong with it?

UPD: The operation hadn't been canceled so I had to reboot. After rebooting I can't open a mounted USB drive because of "Input/Output error".

dmesg information from plugging the USB drive till cancelling the operation. There were no new messages during cancelling though.

[  706.567270] usb 1-1.2: new high-speed USB device number 5 using ehci-pci
[  706.680148] usb 1-1.2: New USB device found, idVendor=abcd, idProduct=1234
[  706.680150] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  706.680152] usb 1-1.2: Product: 1
[  706.680153] usb 1-1.2: Manufacturer: 1
[  706.680154] usb 1-1.2: SerialNumber: Љ
[  706.680468] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[  706.680578] scsi host5: usb-storage 1-1.2:1.0
[  707.699900] scsi 5:0:0:0: Direct-Access     General  UDisk            5.00 PQ: 0 ANSI: 2
[  707.700499] sd 5:0:0:0: Attached scsi generic sg2 type 0
[  707.700872] sd 5:0:0:0: [sdb] 31334400 512-byte logical blocks: (16.0 GB/14.9 GiB)
[  707.701499] sd 5:0:0:0: [sdb] Write Protect is off
[  707.701502] sd 5:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[  707.702118] sd 5:0:0:0: [sdb] No Caching mode page found
[  707.702123] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[  707.706241]  sdb: sdb1
[  707.709381] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[  707.958644] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
  • Looks like the program is hung. Get its ID with pgrep caja and then kill it, or use pkill caja. Is there any further movement on the progress bar?
    – Patrick
    Aug 30, 2017 at 16:14
  • Is it always the case that cancelling takes a long time or is this the first time cancelling the operation took this long / did not work? Check the kernel log (e.g. by running dmesg) for any messages related to the USB drive. It could be the case that the USB drive is damaged, and that could also explain the problem when you attempted to cancel the operation.
    – njsg
    Aug 30, 2017 at 16:39
  • Maybe the hardware error(s) occurred even before you tried to cancel the process but you just did not notice. I/O errors are the end of a software discussion. Aug 30, 2017 at 16:40
  • @njsg It happens with any USB drives. There were two errors in the kernel log: '[sdb] No Caching mode page found' and '[sdb] Assuming drive cache: write through', but I think they don't related to this problem because they happened before cancelling the operation.
    – ntrsBIG
    Aug 30, 2017 at 18:03
  • @Patrick Force quit of caja wasn't the best idea. I killed it, my desktop disappeared and Caja stopped to work. The system couldn't be restarted because there were several hung processes of Caja - copying files and something related to Caja too.
    – ntrsBIG
    Aug 30, 2017 at 18:27

1 Answer 1


I've found one of the ways to solve this problem, it is changing the values of IO buffer variables dirty_bytes and dirty_background_bytes.

I wrote these values (31457280 = 30 * 1024 * 1024) to self-titled files:

echo 31457280 | sudo tee /proc/sys/vm/dirty_bytes
echo 31457280 | sudo tee /proc/sys/vm/dirty_background_bytes

These values work in my case, but you should experiment with them.

In order to save these values after reboot write this in the file /etc/sysctl.conf:

vm.dirty_bytes = 31457280
vm.dirty_background_bytes = 31457280
  • I updated the echo/sudo commands to something a bit closer to what could work; if I'm wrong about what you typed, please update it again.
    – Jeff Schaller
    Sep 3, 2017 at 12:22

You must log in to answer this question.

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