Backup fails with umount problem - target is busy

[Anonymous]

(Equipment list at end of post.)

The problem is repeated failures to complete the backup with the message:
Failed to run command: umount /dev.sdan

umount:/tmp/rescuezilla/.ntfs,mount: target is busy

(could not figure out how to insert attached image here)

This occurs almost as frequently as backups are successful. It happens on all three computers. It happens regardless of which NAS is the target.

Repeating the operation generally results in a complete image, but I have had to try 3 or 4 tries to get an image. The device that fails to unmount varies. It might be the first partition, or any other, right up to the last. It does not seem to be affected whether any of the other computers are in use or not.

A secondary question: If the failure occurs on the last partition, a directory is saved which appears to be a full image, e.g. /media/D-Link/DiskImages-1st/Dell-5520/sada9failed. Is it possible that this is a restorable image?)

Equipment:
Computers: Dual boot, Linux Mint installed after Windows 10, both OSs updated and current (3 “experienced” Dell computers of various models are involved in the problem.)

The network is hosted on a Netgear Nighthawk using cabled Ethernet.

Backup device: D-Link DNS-323 1tB drives configured as Raid 1 or D-Link DNS-325 500mB drives configured as Raid 1. Connection to the NAS is by SMB version 1.0 and Ethernet

All backup attempts are full disk images to the NAS. Plenty of space for the image on the NAS.

[Anonymous]

My best guess would be that it's something related to having two different OSs installed on the same drive. I have never tested Rescuezilla with a dual-boot system. I'm not a fan of such systems and have not had a dual-boot system since about 2005.

Perhaps try backing up a single partition as a test.

I would not assume that after a Backup Failed message that the file would be good.

Another test I try in the case I get an odd failure is to try another version of Rescuezilla or attempt the same operation with Clonezilla.

[Anonymous]

For the next person who finds their way here, I had this issue and was unable to solve. Eventually went with foxclone and it worked right away. Hopefully it completes when I check in the mornin. My target drive was smaller than my source drive, I don't know if that was related? I went all through my windows and BIOS settings and turned of any fastboot, hibernation, sleep, even anything where windows seemed like it might be hinting it's tired and "maybe isn't it better if we just call in a night?"

Which I ought to have said yes to a couple hours ago if I'd been smart.

Only windows (11 Pro) is installed on that computer, although I do frequently use a stick-boot copy of linux mint on that computer to access the internet on the linux boot and save downloads onto the NTFS sdc3 partition, as I keep the windows offline.

Troubleshooting I tried? I killed a process I found with some grep one time, umounted all of /tmp/, with -f or -l and also seemed to succeed one time with the partition /dev/sdc3, didn't really keep track of all of it but ultimately it was a wasted effort. I'm not great at linux syntax yet.

I was using ventoy, if it makes any difference, I know it's not a lot if the next person has a similar issue, but I did wonder afterwards if the wrong error message was possibly popping up? It seemed a little like Rescuezilla was saying "I can't unmount this because I'm using it." I think rescuezilla was the only name I saw with findmnt, anyway.

[Anonymous]

I also had the following message,
"Failed to run command: umount /dev.sdbn".
I tried many times. In some cases, it was sdb3, in other cases, it was sdb5.
This, with Rescuezilla 2.6. I finally used Rescuezilla 2.5.1 and it worked.
I experienced this problem with one computer only. Its ssd disk sdb contains Windows 11, a DATA partition, Debian 12 and Ubuntu 24.04.

[Rescuezilla]

Sorry for the lack of communication on this umount: /tmp/rescuezilla.ntfs.mount target is busy" error.

I can reproduce it consistently in my automated integration test suite environment, but less consistently in the live environment. It impacts drives with NTFS partitions when making a 'Backup' or 'Clone', on some systems.

I have created an initial workaround that removes the incidence of this issue in my environment. Unfortunately a sync to flush the buffers was insufficient so I had to add a 1 second wait between that specific operation, which is not the correct solution (as it doesn't wait for the internal operation that was causing the umount to fail to finish) but I think it will provides an adequate workaround until I find a better way.

Will be available in Rescuezilla v2.6.1 to be released within a week hopefully. The main task to release v2.6.1 is I want to make my automated integration test suite environment run at least once daily in the cloud.