I can’t seem to delete a folder. I tried deleting it via rm -rf /path/to/folder, which printed some i/o error.
I then went to the GUI (Dolphin in my case on KDE) and moved it to the trash, which - to my surprise - worked.
However, after that I tried deleting all files in the bin, which did not work. Also, restoring it isn’t possible either now, so I have this folder sitting in my trash in limbo, unable to delete it, unable to restore it.
yeah sorry, I updated the post to reflect that I executed it on the path. But you’re totally right regarding the rm -rf command. Maybe that was the issue to begin with
In the meantime it somehow went to the .Trash-1000 folder. The exact location now is
/mnt/disk1/.Trash-1000/files/_unpack (4)/
Oddly enough, if I do it via GUI it indeed moves to the trash, but it somehow creates a copy in that location, i.e. it’s called “_unpack (4)” and if I move this to the trash it’s called “_unpack (5)” in the same location afterwards. The hell is going on?
If I try empyting the trash it says it can’t be deleted
Then open Dolphin with sudo rights and clean your trash?
Edit:
I have not much experience with the KDE Trash Feature,
but i think that this feature is mainly designed for deleting files/folders under your Home partition and not your Root.
If this is not helping, you could also try to delete your files from a Liveboot or with TTY.
So, I opened KDEs file browser (Dolphin) as root and successfully deleted the file via rooted GUI. However, the file somehow and somewhere still seems to be present, as another program and command - mergerfs.fsck - still reports
mergerfs.fsck -v -f manual /mnt/mergerfs
Traceback (most recent call last):
File "/usr/bin/mergerfs.fsck", line 225, in <module>
main()
File "/usr/bin/mergerfs.fsck", line 212, in main
check_consistancy(fullpath,verbose,size,fix)
File "/usr/bin/mergerfs.fsck", line 149, in check_consistancy
paths = lgetxattr(fullpath,"user.mergerfs.allpaths")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/mergerfs.fsck", line 46, in lgetxattr
raise IOError(err,os.strerror(err),path)
FileNotFoundError: [Errno 2] No such file or directory: b'/mnt/mergerfs/.Trash-0/files/_unpack (4)
I have no idea what to do. That’s basically why I noticed that there’s something wrong with that file after executing mergerfs.fsck.
I’ll give your tty suggestion a go
Sorry, I just noticed that the error mergerfs is printing refers to another folder in .Trash-0, not .Trash-1000.
However, I’m able to delete that as well, but right after I deleted it via GUI + root, it’s right back there
FSCK Filesystem scan, best way in Lifeboot:
sudo fsck -f -y /dev/sdXX (-f Forcescan -y always yes to all questions) (sdXX Replace XX with your unmounted drive that needs to be scanned)
If you use BTRFS as your Filesystem, then im have to pass.
Trashed files remain on the drive where they were originally located. Your home Trash folder is located at ~/.local/share/Trash/. Trash folders on other mounted drives will be located on those drives as a hidden folder called .Trash-1000 (or whatever your UID is - usually 1000 on a single-user system).
For example, I have a 14TB WD Elements external drive attached to my PC, and its Trash location is /run/media/scotty/14TB-Elements/.Trash-1000/. However, Trash in Dolphin displays all of my Trash locations in one view, no matter whether they are located on my SSD or on an external drive.
I have to disagree with that. There are several options to properly mount NTFS drives in (Arch) Linux. Also I never had issues with that and I doubt that it has solely to do with the drive being formatted as NTFS.
However, I tried it with TTY - no luck. In tty it just tells me that the file or folder doesn’t exist.
As the issues arose yesterday evening, right after lightning stroke something in the tiny village I live in and the electricity was cut for a moment, it might just be the case that the drive has errors now. Currently, I can’t come up with a better explanation.
If anybody else has another idea I’m glad to hear it though.
If you cannot remove a file or a folder - your mount permissions does not allow for writing.
Please search the forum. It has been explained over and over - please search.
Even though you may not find a description of your exact issue with trash - but - like it or not - it all boils down to the NTFS filesystem and how the driver handles inconsistencies.
There is so many topics on problems with NTFS which is mounted readonly especially the confusion about which driver is used.
kernel driver (ntfs3)
userspace (ntfs-3g)
NOTE: A NTFS partition may flagged dirty by Windows (set when Windows is not shutdown clean) and in such case the kernel driver will only mount readonly.
In such case you need to use Windows to run a diskcheck or manually mount using the force flag or use ntfs-3g utility to clear the flag.
Only in post 6 you are revealing you are using mergefs - I so totally missed this.
This is an unsupported custom package
Moved your topic to AUR section
This is root trash
This is user trash
So it is now clear that because you are not emptying trash as root - you cannot get to empty it fully.
But the safest approach is to actually scan/clean/correct the filesystem. Much like you would with fsck except linux utilities only support clearing the dirty bit. In order to properly handle any possible issues one must use chkdsk on windoze or a PE/clone.
Failing to do so runs the risk of continued damage.
This is one of the many reasons one would probably avoid NTFS for a linux system.
(other considerations may include the discrepancy between case-sensitivity, etc)
If you cannot delete files, then your permissions are wrong. You can take a look at the 2024-04-04 stable announcement known issues about example of proper ntfs permissions.
this may be a problem - if you combine different filesystems perhaps
The easy way out is to unmount the merged filesystems and go to each one separately and look for and delete your files
Or boot an ISO from usb and do the same.
mergerfs is not present there, so this is the only way anyway when working from ISO boot
Thank you all so much for your inputs, advices and suggestions. I would have never let the drive(s) being NTFS in the first place, if there wasn’t critical data on it which I definitely needed to preserve after coming from Windows.
But I know for sure, that this is far from ideal.
May it be as it is.
I was now able to finally resolve the issues by:
Creating a live bootable Windows USB stick
Booting into it and performing chkdsk /f on all my NTFS drives
The check found a bunch of errors and successfully corrected them
After being back in Manjaro the issues are all gone, including the problematic file that I wasn’t able to delete.
