sudo rm -rf devuelve "no se puede eliminar el directorio" en el directorio vacío propiedad de root

8

Tengo un directorio en mi sistema Debian. El directorio es:

root@debian:/3/20150626# stat 00
File: `00'
Size: 6             Blocks: 0          IO Block: 4096   directory
Device: fe00h/65024d    Inode: 4392587948  Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-06-25 20:00:00.086150791 -0400
Modify: 2015-07-07 12:39:04.174903234 -0400
Change: 2015-07-07 12:39:04.174903234 -0400
Birth: -

El directorio está vacío:

root@debian:/3/20150626# ls -al 00
total 0
drwxr-xr-x 3 root root  6 Jul  7 12:39 .
drwxr-xr-x 3 root root 23 Jul  7 12:56 ..

Pero mi sistema no lo cree así:

root@debian:/3/20150626# rm -rf 00
rm: cannot remove `00': Directory not empty

No sé por qué sucedería esto ni puedo encontrar una manera de seguir adelante. ¿Alguien puede brindar asistencia?

Ninguna de las preguntas anteriores que pude localizar resolvió este problema específico. Pero, para abordar algunas de las preguntas que he visto en publicaciones similares:

a.) La carpeta fue creada por un proceso en ejecución, que ha creado muchas carpetas antes y estas carpetas se han eliminado muchas veces antes. Este específico está atrapado en el limbo.

b.) No debería haber nada escrito en este directorio ahora. Lo he comprobado muchas veces y la ls -alsalida siempre no devuelve nada.

c.) He comprobado lsof y no hay nada abierto para este directorio:

root@debian:/3/20150626# lsof 00
root@debian:/3/20150626# 

d.) rmno tiene alias para nada más. Está bastante cerca del stock de Debian ... nada especial hecho con ninguno de los principales programas de Bash como rm, etc.

e.) El cambio de nombre está permitido pero aún no se puede eliminar:

root@debian:/3/20150626# mv 00 delete_me
root@debian:/3/20150626# ls -al
total 0
drwxr-xr-x 3 root root  30 Jul  7 13:45 .
drwxr-xr-x 7 root root 105 Jul  7 12:57 ..
drwxr-xr-x 3 root root   6 Jul  7 12:39 delete_me
root@debian:/3/20150626# rm -rf delete_me
rm: cannot remove `delete_me': Directory not empty
root@debian:/3/20150626# ls -al delete_me/
total 0
drwxr-xr-x 3 root root  6 Jul  7 12:39 .
drwxr-xr-x 3 root root 30 Jul  7 13:45 ..

** Nota, en lo sucesivo referido como "delete_me" ya que lo renombré y solo voy a seguir con el flujo.

f.) Este es el único directorio que se devuelve cuando lo ejecuto find.

root@debian:/3/20150626# find / -type d -name delete_me
/3/20150626/delete_me
root@debian:/3/20150626# find delete_me
delete_me

g.) lsattr no muestra nada:

root@debian:/3/20150626# lsattr
---------------- ./delete_me
Harperville
fuente
1
¿Es posible cambiar el nombre del directorio?
Jenny D
2
La parte de "Enlaces: 3" me llama la atención; parece que podría tener un subdirectorio. ¿Qué devuelve "find 00"?
Jeff Schaller
Actualicé mi pregunta con una respuesta a la suya, @JennyD
harperville
1
¿Ha verificado lsattrsi hay algún atributo especial asignado?
Caja
2
Me parece cada vez más probable que este proceso en ejecución desde el elemento (a) se aferre a un subdirectorio de "delete_me" de alguna manera. ¿Puede detener este proceso en ejecución y luego volver a verificar la statsalida (y / o volver a intentar el rmdir)?
Jeff Schaller

Respuestas:

1

Encontré la respuesta. Algo estaba mal con el enlace, como sugirió @JeffSchaller. La solución es ejecutar xfs_check para ver que los enlaces eran incorrectos, luego xfs_repair para corregirlos.

  1. ejecutar mountpara ver el nombre del dispositivo. El mio es/dev/mapper/vg3-lv3
  2. umount /3
  3. xfs_check /dev/mapper/vg3-lv3 que devolvió lo siguiente:

    link count mismatch for inode 4392587948 (name ?), nlink 3, counted 2

    link count mismatch for inode 12983188890 (name ?), nlink 1, counted 2

  4. xfs_repair /dev/mapper/vg3-lv3 que indicó que los enlaces fueron corregidos:

    resetting inode 4392587948 nlinks from 3 to 2

    resetting inode 12983188890 nlinks from 1 to 2

Resulta que tenía otro inodo que estaba vinculado incorrectamente.

Gracias por toda la ayuda, pero usando la magia negra de xfs_repair, mi problema está resuelto.

Harperville
fuente
-1

Intentó verificar que los atributos de la carpeta / directorio tengan el atributo " i ": ¡imutable está activo! Verifique con el comando lsattr para verificar que la carpeta / directorio tenga activado el atributo " i " si lo desactiva con "*

chattr -i ' carpeta '

* "Con esto puedes realizar la tarea que quieras.

Broma Sr. OK
fuente
1
El -iatributo en un archivo / carpeta no impide que aparezca, sin embargo, ¿dónde ves que -iestá configurado? La salida de OP indica lo contrario
kos