Stale file handle - can't delete file even with rm -f

Manjaro XFCE 25.0.10 latest updates
Kernel : 6.16.8-1

I have a directory in which I have problems.

ls -a

ls: cannot access ‘.~lock.2025 HAPPINESS Lifestyle Purpose Agenda Result – put this in a dash board.ods#’: Invalid argument
ls: cannot access ‘lu4150za92.tmp’: Stale file handle
total 9008
drwxr-xr-x 1 x245 x245 8192 19 nov 09:40 .
drwxr-xr-x 1 x245 x245 8192 19 nov 16:11 ..
-??? ? ? ? ? ? ‘.~lock.2025 HAPPINESS Lifestyle Purpose Agenda Result – put this in a dash board.ods#’
-??? ? ? ? ? ? lu4150za92.tmp

I tried:

rm lu4150za92.tmp
rm: cannot remove ‘lu4150za92.tmp’: Stale file handle

even with: sudo rm -f lu4150za92.tmp

I also tried to shutdown and ran:

sudo ntfsfix -d /dev/sda5

then tried again to delete to no avail.

How can I solve the problem?

I think it happened a month ago while I was with LibreOffice open and had a power failure.
Amongst, the issues are Thunar 4.20.5 can simply not access the directory content, while Dolphin 25.08.1 can (and does not show the 2 problematic files).

with Thunar, when I access the directory which contains the 2 problematic files, I have this:

sudo journalctl -b | grep -i ntfs3

nov 19 18:19:31 x245 kernel: ntfs3(sda5): MFT: r=86df, expect seq=c instead of 48!
nov 19 18:19:31 x245 kernel: ntfs3(sda5): Inode r=80d7 is not in use!
nov 19 18:19:31 x245 kernel: ntfs3(sda5): Inode r=80d7 is not in use!
nov 19 18:19:31 x245 kernel: ntfs3(sda5): Inode r=80d7 is not in use!
nov 19 18:19:31 x245 kernel: ntfs3(sda5): MFT: r=86df, expect seq=c instead of 48!

If I access the parent directory, I see at that moment:

nov 19 18:23:57 x245 kernel: ntfs3(sda5): MFT: r=86df, expect seq=c instead of 48!
nov 19 18:23:57 x245 kernel: ntfs3(sda5): Inode r=80d7 is not in use!

Thanks

The filesystem is obviously damaged, but the ntfsfix utility isn’t really any good. Given that it’s an ntfs filesystem, you should boot up in Windows and repair the filesystem with CHKDSK.EXE.

P.S.: For your sake, I do hope that you did not install Manjaro on ntfs. GNU/Linux is a UNIX-family operating system and requires being installed on a filesystem that supports POSIX permissions and file ownership. ntfs is not a POSIX filesystem and cannot store that kind of metadata.

4 Likes

No ext4.

you should boot up in Windows and repair the filesystem with CHKDSK.EXE.

Can’t boot on windows, because since then, I have reformated that sys partition and replaced it by Manjaro.
The internal hdd ntfs partition is where the data are and were.

You can download a Windows system rescue ISO, put it on a USB stick with ventoy, and boot up from it. :backhand_index_pointing_down:

ventoy is in the repository, so you can install it via your package manager. It’s super-easy to use, because it formats the stick in a special way. After that, you simply drag-and-drop ISOs to the Ventoy folder — as many as the stick will hold — and then when you boot up from the stick, it’ll show you a menu with all of the ISOs.

2 Likes

Thanks, I’ll try but suppose the partition was in ext4 or Btrfs, how then solve the problem?
I mean, there is no way Linux can solve the issue?

Start gparted. It will show you what type of filesystem the partition has

Not if the filesystem is NTFS !

If you are not using Windows, then please do not use NTFS!
:footprints:

3 Likes

You could try to install ntfs-3g driver which is less picky with regard to small file system damages or inconsistencies. If you can access the file system then I would recommend first to make a backup of all other files before trying to delete some files. When you have backed up you could also just reformat that partition and re-copy from the backup.

4 Likes

ext4 and btrfs have their own repair utilities. But ntfs is a proprietary, non-POSIX filesystem, and therefore a moving target. The ntfsfix utility was an attempt to reverse-engineer a repair utility for it, but it’s not exactly the best option for fixing errors on ntfs.

3 Likes

Well, for the people who wanted to move from win10 to Linux due to the impossibility to upgrade to win11, better know in advance.

So in a sense, your advice is get an external hdd at least as big as the internal hdd.

  1. Make a copy of the internal hdd in ntfs using an external hdd in ext4
  2. reformat the internal hdd in ext4.
  3. take the external drive copy and now re-import to the newly formated internal hdd.

All that for 2 files?

No, all of that because of the unreliability of ntfs and whatever future issues you may have with it. In and of itself, and even when used in Windows, ntfs is a horrible filesystem, plus that it’s an alien, non-POSIX filesystem.

Furthermore, you need a suitable medium for storing backups, and while an internal drive can be used for that, an external one is even better.

2 Likes

No, it’s to ensure your data remains secure in the future.

(And my recommendation would be btrfs, not ext4) :footprints:

2 Likes

No.
NTFS usually works fine.
For file storage.
But if there are errors in the file system - this does happen, like in your case - there is simply no reliable way to actually fix them with Linux only tools.
For that you’ll always have to have things like these at hand:

Use one of these and check and repair your NTFS file system with tools native to Windows
and you’ll likely be fine - until the next time there is an error for whatever reason.

2 Likes

>(And my recommendation would be btrfs, not ext4)
I though btrfs for SDD and ext4 for HDD

Gparted an external usb HDD in ext4.

By default Gparted seems to make root sole user
sudo chown -R $USER:$USER “/run/media/$USER /extPART”/

Thunar refused to copy, Dolphin made the copy.

Either filesystem is suitable for use on SSDs and HDDs. But ext4 is rather old-school and basically the end of the line in how far the developers can keep on improving the ext family of filesystems. btrfs on the other hand is a very modern copy-on-write filesystem with loads of very advanced features.

That has nothing to do with gparted, but with the way systemd — or more specifically, udisks2 — mounts the filesystem.

Also note that the /run hierarchy exists only in virtual memory, and that as such, any changes to a mountpoint in there will be gone after a reboot.

I’ve written an extensive tutorial on how to work with additional drives. I recommend you read it. :wink:

:backhand_index_pointing_down:

1 Like

Should I file some bug regarding Thunar?
On the other hand, if Dolphin did the copy, it failed to warn about the issue.

I don’t think so.

dolphin is polkit-aware and will prompt you for a password when elevated privileges are required.

But then again, if you changed the ownership — as you said you did — and you have not rebooted since, then no elevated permissions would have been required.

Still, do read my tutorial. :wink:

Sorry, but there is a misunderstanding I wasn’t refering to priviledges.

I meant, that due to the stale file handle,
1/ in the case of Thunar it does not copy at all the directory (3Gb), eventhough you can access any dir to the exception of the one containing the stale file handle

2/ in case of Dolphin, it does copy everything to the exeception of stale file handle and allows to see everything. However, Dolphin never warned about an issue.

And yet, you are working with a damaged filesystem. This is uncharted territory and i doubt filemanagers are tested for this use scenario. So it does not really matter how they cope with it. And of course, continuing to use it you will probably damage it more.
The solution is clear: checkdisk.

4 Likes

thunar is probably being conservative in that regard, while dolphin is a bit more sophisticated.


Indeed. :wink:

1 Like

Regarding NTFS (only):

If the problem is accessing files on an ntfs filesystem that’s damaged, the only reliable resolve is to repair the filesystem using Microsoft’s own proprietary tool chkdsk.exe in a Windows environment (as mentioned earlier) in order to hopefully access your files.

As you no longer have a Windows installation, chkdsk.exe can also be run from a bootable DVD/ISO/USB such as Hiren’s Boot, also mentioned previously.

If you would like a deeper understanding of some of the points raised (re: ntfs) you might find the following article of interest.

It’s a long read with a lot of important detail, but it does cover many things you should be aware of with respect Linux on NTFS.

Regards.

4 Likes