1

I want to delete a backup of a website (FTP-mirrored with wget), but a single file, named js_composer.less resists. I can create new files and delete them in the same directory, so the problem might be with the file itself.

It can't be force-deleted:

$sudo rm -f js_composer.less
rm: cannot remove 'js_composer.less': Operation not permitted

I can't change its permissions:

$sudo chmod 644 js_composer.less
chmod: changing permissions of 'js_composer.less': Operation not permitted

I can't change its owner:

$sudo chown myuser:mygroup js_composer.less
chown: changing ownership of 'js_composer.less': Operation not permitted

I can't list the file's attributes:

$sudo lsattr js_composer.less 
lsattr: Operation not supported While reading flags on js_composer.less

From ls I can see that it's a named pipe (FIFO) with sticky bit (restricted deletion flag) applied:

p-ws-wS--t 41284 30917 5212 3944510081 márc  14  1902 js_composer.less

Now I don't see any way to get rid of this file. What else could I try?

Márton Tamás
  • 113
  • 6

1 Answers1

1

It's an item with nonsense permissions and 41284 hardlinks. It's a named pipe with alleged size of 3.7 GiB, which is 3.7 GiB larger than a named pipe should be (and it wasn't supposed to be a named pipe in the first place).

It's a sign that you shouldn't be trying to delete it – instead you should be running fsck against the partition and letting it fix any filesystem corruption that it can find. Then you might be able to simply delete the bad file.

If this happened on your root filesystem, reboot with the kernel option fsck.mode=force. If the filesystem is separate (e.g. you have a separate /home partition), you can alternatively reboot into recovery mode and run fsck <device> manually.

After the check finishes, try rebooting into normal mode and removing the file again.

Finally, if nothing else helps, most filesystems have "debugfs"-type tools which can directly edit and remove inodes and directory entries, bypassing the kernel's filesystem code. For example, ext4 has debugfs and XFS has xfs_db. Using them would be a separate thread on its own...

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Thank You, that's probably the case. There has been some partition warnings and repairs going on at system startup lately. The file is on my separate home partition, I just need to figure out, how to enter recovery mode in my Libreboot (: I'll get back to You when I've tried it. – Márton Tamás May 12 '20 at 09:24
  • I made a live USB, booted in it, mounted the encrypted disk, then ran `sudo fsck /dev/mapper/master-home`. It outputted "clean", which I guess means it didn't find any errors, but it was very quick, almost instantaneous, which I find suspicious. Should I go aloing with `debugfs` tools? – Márton Tamás May 12 '20 at 10:00
  • 1
    Run it with the `-f` option to perform a full check. – u1686_grawity May 12 '20 at 11:04
  • Thanks. Actually I had to specify the FS type, so it was `sudo fsck.ext4 -f /dev/mapper/master-home`, but it worked (I've never did a FS check manually before). And of course, all the errors were related to that single inode. After accepting all the repairs, the file was gone. – Márton Tamás May 12 '20 at 12:51