Unmount fails and errors requiring chkdsk /f in windows, ntfs partitions

I keep getting Warnings next to two of my data partitions (Work and Documents) in Gparted that tell me:

Forced to continue.
$MFTMirr does not match $MFT (record 3).
Failed to mount ‘/dev/sda6’: Input/output error
NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
The usage of the /f parameter is very IMPORTANT! No modification was
made to NTFS by this software.

I can do this in Windows, as I have dualboot, but they keep coming back

I also noticed that on shutdown, unmounting these two partitions fails

leigh@archlabs ~ % journalctl -b -1 --grep="failed unmounting"
Nov 06 18:08:20 archlabs systemd[1]: Failed unmounting /run/media/leigh/Documents.
Nov 06 18:08:20 archlabs systemd[1]: Failed unmounting /run/media/leigh/Work.

However, neither of the two errors above happen to my other (ntfs) data partition LaptopMusic, strangely

My fstab:

leigh@archlabs ~ % cat /etc/fstab
# /dev/sdb2
UUID=e39d8e26-bfbc-4b98-82aa-b9f517273ad2	/         	ext4      	rw,relatime	0 1

# /dev/sdb1
UUID=CC47-FF0C      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/sda5
UUID=d06f9174-8e6f-46d0-a610-295cc5bd817a	none      	swap      	defaults  	0 0

LABEL=Documents /run/media/leigh/Documents ntfs3 nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=984 0 0
LABEL=Work /run/media/leigh/Work ntfs3 nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=984 0 0
LABEL=LaptopMusic /run/media/leigh/LaptopMusic ntfs3 nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=984 0 0

I am using Thunar, where I have Enable Volume Management activated (I cant remember if this is default or I did it for some reason). But when I try to click on ‘configure’ for this I get an error:

Failed to display the volume management settings
Failed to execute child process “thunar-volman” (no such file or directory)

EDIT: writing the post often gives me ideas :slight_smile: so I disabled the Volume Management in Thunar but still got the failed to unmount errors

so, is any of the above linked, and any ideas how to stop these errors, please?

I have already done a lot of searching but am going round in circles now :frowning_face:

You mean you ran chkdsk /f on the partitions?

Do a search of this error:

$MFTMirr does not match $MFT (record 3).

Looks like you may have an issue with your file system (scroll to bottom comment). If you have the ntfs-3g package installed (should be by default) you should have all the utilities including ntfsfix which is usually used to fix the issue. Be careful with the ntfsprogs - back up all that data before using them.


Thanks @PackRat

Yes, I boot into windows and run

  • Documents
    • chkdsk d: /f
  • Work
    • chkdsk e: /f

Actually, this only gives any errors for Work (which was an invalid filename I think), no errors for Documents partition

Then reboot Windows twice

Then boot back into AL, but GParted shows same errors

I think that there is no point in trying the ntfsfix command in Linux, as that last comment in that thread says,

But because it is NTFS, the only way to truly repair NTFS is Windows’ chkdsk utility. (There is a ntfsfix command, but it is NOT going to be of the same quality of fix as Windows’ utilities to check NTFS disks).

and since it is so easy for me to boot into windows and use chkdsk, I do that (although that didnt work …)

Its worth noting that, except for those errors in GParted, both partitions mount perfectly well and I can use them without problems (both in AL and Win)

What about that failed to unmount error when shutting down AL - is that a problem - is it like disconnecting a disk without unmounting it? should I be worried about that?

And why should it happen to only 2 out of 3 ntfs partitions on my system, especially because Documents is on sda, and both Work & LaptopMusic are on sdb?

Need a new post, or edits will get confusing:

  1. I thought, sod it - I will try anyway, so (after realising that I had to unmount the two partitions first) I ran ntfsfix and it removed the errors in GParted!
leigh@archlabs ~ % sudo ntfsfix /dev/sdb3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdb3 was processed successfully.
  1. BUT … on reboot the two partitions (Work and Documents) did not automatically mount, and Thunar couldnt mount them either (again, LaptopMusic was fine). Funnily enough Gparted could mount them.

  2. So, I rebooted into Windows and ran

  • For Documents:
    chkdsk d: /f
  • For Work:
    chkdsk e: /f

No errors found for either,
Then I rebooted into windows twice, as instructed.

  1. On Rebooting into AL, all data partitions (work and Documents, plus LaptopMusic) automatically mounted fine this time, BUT …

The errors are back in GParted :frowning:

I have to use ntfs as I still need Windows for work

I am starting to think that I should just gnore the errors in Gparted as everything seems to work.

OK, after the EDIT below, this is my big question now - Are those ‘Failed to unmount’ errors on AL shutdown to worry about? If so / anyway, is there a way to avoid them?

(I’m also a bit miffed that I cant understand whats happening, especially the thing about LaptopMusic showing no errors or anything when its setup identically to the other two - the only difference I can think of is that my Nextcloud client which starts at startup syncs folders on the other two partitions but not on LaptopMusic - but I might have to let that lie)

EDIT: If I unmount Documents and Work partitions in Thunar before opening Gparted, the errors disappear from GParted :smiley: So presumably those errors in GParted are just telling me that it cant mount them as they are already mounted?

OK, I am sure no one cares :rofl: but maybe someone with a similar problem will stumble across this in the future.

The reason why those two partitions were failing to unmount was indeed because they were still being ‘used’ by my Nextcloud client on shutdown (LaptopMusic is not in my Nextcloud sync so it was unaffected)

If I shutdown my Nextcloud client before shutting down the system, the ‘Failed to Unmount’ errors disappear :slight_smile:

Next task is to try to work out how to make sure how ArchLabs shutrs down Nextcloud before trying to unmount those partitions … Anyone know, please?

1 Like

Wonder if it can be of any help to you @leigh


You should be able to write a simple systemd service that will perform that task prior to shutdown. A quick search found this example; similar situation but with Google Drive. Another example - systemd run script/command before shutdown.

Another option would be a simple bash script that shuts down Nextcloud then shuts down AL. That could be made into a menu entry and/or key binding.

Can you shut down Nextcloud from the command line?


Thanks @altman , but my Nextcloud is working and I dont want to touch it :rofl:

Thanks @PackRat

pkill nextcloud works

I can now look into both ways you suggested

I think I’d like to try to systemd one first, never done anything like that before
Will post back with a result if it works


1 Like

Oh @leigh , only on exit then, Don t exit ! lol

Is that a server in a company of some sort !

1 Like

Hi! I was trying to get the systemd approach working (was getting complex) when I thought of another, easier route, similar to your script for menu entry / keybind suggestion.

I already customized the rofi_run script to add a suspend option, so I just included the pkill nextcloud command in there as well (I needed a sleep 1 to give Nextcloud client time to shutdown):

rofi_run script (Super+X) customisation

  1. Add suspend option
  2. Kill nextcloud client to avoid failed unmount of Work and Documents partitions on shutdown and reboot (sleep 1 to give nextcloud time to shutdown).


  1. Add the suspend parts (3rd & 7th lines in part below) to the script
  2. Add pkill nextcloud && sleep 1 && to the *Reboot) & *Shutdown) lines
				case "$(rofi -sep "|" -dmenu -i -p 'System' -width 20 -hide-scrollbar \
					-line-padding 4 -padding 20 -lines 5 <<< " Lock| Logout| Reboot|Z Suspend| Shutdown")" in
					*Lock) i3lock-fancy ;;
					*Reboot) pkill nextcloud && sleep 1 && systemctl reboot ;;
					*Shutdown) pkill nextcloud && sleep 1 && systemctl -i poweroff ;;
					*Suspend) systemctl suspend ;;
					*Logout) session-logout >/dev/null 2>&1 || pkill -15 -t tty"$XDG_VTNR" Xorg ;;

It worked!

Thanks for help!

EDIT: Or perhaps I could have replaced systemctl -i poweroff with shutdown now?

But that wouldnt work for reboot …

1 Like
systemctl reboot

Not sure I understand you there @sammiev

I guess I could replace systemctl reboot with shutdown -r now but I am not sure if that would kill Nextcloud client first either?

You mean use only those commands instead of shutting down Nextcloud with pkill prior to shutdown/reboot?

You can run those commands from a terminal and see if they work the way you want. Note the comment from that reddit entry:

shutdown now allows itself to be delayed by Linux services as they attempt to exit gracefully. Can result in a hung system requiring manual power off


Doh! How could I not have thought of trying that :smiley:

Both shutdown now and shutdown -r now give me the failed unmounting warnings, so they dont kill the Nextcloud client first.

So I will stick with my pkill solution

I did note that comment, but given that using shutdown isn’t ‘graceful’ enough to kill Nextcloud, it doesn’t matter :smiley:

Thanks for your help, again @PackRat !

I’m a bit late to this but have you tried systemctl poweroff without the -i flag? Pretty sure that just forces a shutdown without waiting for services to exit.

$ls -las /usr/bin/shutdown

$ls -las /usr/bin/reboot

should give you an idea how to approach it. A little more “graceful” way is to use systemd unit (like @PackRat suggested before).

I have now - it gives the same failed to unmount warnings.

Ah, so they both use systemctl anyway?

I like my way of using the rofi_run script - it works and is simple so it suits me :smiley:

In the spirit of leaving clear info:

It turns out I had two ‘issues’ that I am pretty sure are not related:

  1. The fail to unmount partitions on shutdown / reboot issue, solved (with help from others, obviously) in this post

  2. The errors showing in Gparted which were because the partitions had already been mounted in my fstab. If I open gparted with the partitions already mounted then the warnings are there, and if I then unmount the partitions (I used Thunar) and refresh Gparted, the warning have disappeared. So I take this to mean the Windows chkdsk /f is not required and the Gparted errors are not a consequence of the failed to unmount warnings on shutdown / reboot of 1. abaove

At least, that’s what I think!

you have piqued my interest there :smiley:

leigh@archlabs ~ % ls -las /usr/bin/reboot
0 lrwxrwxrwx 1 root root 9 Nov  3 16:18 /usr/bin/reboot -> systemctl*
leigh@archlabs ~ % ls -las /usr/bin/shutdown
0 lrwxrwxrwx 1 root root 9 Nov  3 16:18 /usr/bin/shutdown -> systemctl*

so both are links (symbolic?) to sytemctl, but they must ‘call’ systemctl in different ways, how do I see how they do this?
Please :smiley:

I dont know the terminology well enough to search successfully

Edit: but getting warm?

Yea when you run a program it has a list of arguments, first (zeroth) of which is the program name. The program can then execute different things based on what the name it was called with.

The link you found sums it up perfectly.

1 Like

Thanks @natemaia ,

I just realised that my solution (butchering your rofi_run script) means that if nextcloud is not running then shuttdown or reboot via rofi fail.

How could I make it so that it wont fail if there is no nextcloud to pkill?