10

How can I delete this directory? I did fsck and it has found some garbage, I looked through these files and there wasn't something important. So I've tried to delete the contents of /lost+found and everything has gone except this strange directory. I thought that putting it to /tmp (I can move that dir across the volume) will erase it on next reboot but it's still there after both reboot and another fsck.

As it seems like the problem is low level and playing with ownership and permissions is not enough, I've made you able to reproduce the issue by yourself. Enjoy!

  • This is safe, you will be able to umount image to get rid of these directories on your machine;
  • This s not iso-image, this is the result of dd if=/dev/sda1 of=/files/broken.iso;

I've made a 15MB archive with the image which is ~1.2GB. You can download and ply with it with the following commands:

cd /tmp
wget https://dl.dropboxusercontent.com/u/22701362/broken.tar.xz
tar xvf broken.tar.xz
mkdir test
sudo mount broken.iso test
cd test

There would be two directories (During the creation of that image it appears that there are two such directories on my disk):

/tmp/test> tree
.
├── 1
│   └── plexus-component-annotations-1.5.5.jar.sha1 [error opening dir]
└── 2
    └── #1589030 [error opening dir]

4 directories, 0 files

Good luck with removing these two directories:

/tmp/test> sudo rm -rf *
rm: cannot remove '1/plexus-component-annotations-1.5.5.jar.sha1': Operation not permitted
rm: cannot remove '2/#1589030': Operation not permitted

/tmp/test> sudo chown -R root:root *
chown: changing ownership of '1/plexus-component-annotations-1.5.5.jar.sha1': Operation not permitted
chown: cannot read directory '2/#1589030': Permission denied

/tmp/test> sudo chmod -R 777 *
chmod: changing permissions of '1/plexus-component-annotations-1.5.5.jar.sha1': Operation not permitted
chmod: changing permissions of '2/#1589030': Operation not permitted
chmod: cannot read directory '2/#1589030': Permission denied
Grief
  • 473
  • 7
  • 17
  • How is `/tmp` on the same volume? Could you post the output of `df`? Also, please post the output of `sudo perl -MFile::Path -e 'rmtree("/tmp/foo") || die "$!"'` just in case we get a more informative error message. – terdon Jul 03 '16 at 12:38
  • @terdon I've added the output to the question. Do you think the output is even a bit helpful? – Grief Jul 03 '16 at 13:06
  • 1
    Well, the `df` output shows us that your /tmp` is actually a normal directory on `/` and not a tmpfs which is the default setup. That's surprising, but explains both why you could copy the dir to `/tmp` and why it survives reboots. The `perl` output doesn't really add much, no, but it was worth a shot. I'm clutching at straws here. – terdon Jul 03 '16 at 13:09
  • offtopic: in Ubuntu `/tmp` is a normal directory by default. This is done to prevent filling it up to 100% and to save RAM. It is cleaned up during the startup. This behaviour exists for a long time. – Grief Jul 03 '16 at 13:15
  • I'd try booting off a livecd, then poking around the filesystem. – Journeyman Geek Jul 03 '16 at 13:29
  • @JourneymanGeek that didn't help either. However, I am in progress of creating reproducible environment. As soon as I complete cloning/erasing and compressing the partition I'll provide the steps in the question. – Grief Jul 03 '16 at 15:05
  • @JourneymanGeek you can now try removing that dir youself if you have a spare minute. I've added steps-to-reproduce into the question – Grief Jul 03 '16 at 15:19

2 Answers2

8

One possibility is the immutable flag in the case of ext filesystem. See output of lsattr command. If there is i present, it can be removed with chattr -i filename

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

In this case, there is something else happening

This seems to work,

> lsattr 1
-----a---------- 1/plexus-component-annotations-1.5.5.jar.sha1
> rmdir 1/plexus-component-annotations-1.5.5.jar.sha1
rmdir: failed to remove '1/plexus-component-annotations-1.5.5.jar.sha1': Operation not permitted
> chattr -a 1/plexus-component-annotations-1.5.5.jar.sha1
> rmdir 1/plexus-component-annotations-1.5.5.jar.sha1

> lsattr 2
---D-ad--j--T--- 2/#1589030 
> chattr -D -a -d -j -T 2/\#1589030
> rmdir 2/\#1589030
J.J. Hakala
  • 431
  • 3
  • 11
  • Nope. Did you see that I used `sudo`? I would appreciate if you download the image, mount it and try yourself. – Grief Jul 03 '16 at 15:32
  • This is not an 'iso image' this is result of `dd if=/dev/sda1 of=broken.iso` – Grief Jul 03 '16 at 15:37
  • Yes, you are probably right, sorry! Did you have a chance to reproduce the issue? – Grief Jul 03 '16 at 15:42
  • 1
    Yes, and it looks really odd. – J.J. Hakala Jul 03 '16 at 15:48
  • I feel sooo stupid now :( But you are my hero of the day, mr. J.J. Hakala – Grief Jul 03 '16 at 16:01
  • I was too quick. I've deleted the first directory with your help, but the second one gives me: `sudo chattr -D -a -d -j -T 2/\#1589030` : `chattr: Permission denied while reading flags on 2/#1589030` :( – Grief Jul 03 '16 at 16:13
  • @Grief I cannot reproduce that problem with directory 2, those commands work for me. – J.J. Hakala Jul 03 '16 at 16:20
  • I understand. But on my system it's reproducible even with the downloaded and mounted image, I mean everything is the same for you and me except the system. Maybe there is a bug still? – Grief Jul 03 '16 at 16:29
  • I decided to accept your answer and create a separate one regarding `lsattr` issue. Thank you for your help! Here is a new question: http://askubuntu.com/questions/794371/lsattr-permission-denied-while-reading-flags-on-directory – Grief Jul 03 '16 at 16:38
  • if you haven't been setting immutable yourself then at this point it might be better to backup and recreate the filesystem, if its had enough damage to flip bits like that its probably not trustable and probably will be slower in usage – Amias Jul 04 '16 at 10:19
1

try becoming the user that owns it to delete it

sudo -u 6666 -g 19312 rm -rf ./#1589030
Amias
  • 5,207
  • 20
  • 33
  • `sudo -u '#6666' -g '#19311' rm -rf \#1589030` `rm: cannot remove '#1589030': Permission denied` `sudo -u '#6666' -g '#19311' chmod 777 \#1589030` `chmod: cannot access '#1589030': Permission denied` – Grief Jul 03 '16 at 11:23
  • You need to make than user if it doesn't exist – Amias Jul 03 '16 at 16:49
  • creating user and group with these UID and GID didn't help – Grief Jul 03 '16 at 16:57