MySQL:Błąd usuwania bazy danych (errno 13; errno 17; errno 39)

Szybka naprawa

Jeśli chcesz po prostu usunąć bazę danych bez względu na wszystko (ale proszę najpierw przeczytaj cały post:błąd został podany z jakiegoś powodu i może być ważne, aby wiedzieć, jaki był powód!), możesz:

znajdź katalog danych za pomocą polecenia SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
zatrzymaj serwer MySQL (np. service mysql stop lub rcmysqld stop lub podobny w systemie Linux, NET STOP <name of MYSQL service, often MYSQL57 or similar> lub przez SERVICES.MSC w systemie Windows)
przejdź do katalogu danych (tu powinieneś zbadać; patrz poniżej)
usuń katalog o tej samej nazwie co baza danych
uruchom ponownie serwer MySQL i połącz się z nim
wykonaj DROP DATABASE
To wszystko!

Powody Errno 13

MySQL nie ma uprawnień do zapisu w katalogu nadrzędnym, w którym mydb znajduje się folder.

Sprawdź to z

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb

W systemie Linux może się to również zdarzyć, jeśli połączysz i dopasujesz pakiety MySQL i AppArmor/SELinux. Dzieje się tak, że AppArmor oczekuje, że mysqld będzie miał swoje dane w /path/to/data/dir i zezwala tam na pełne R/W, ale MySQLd pochodzi z innej dystrybucji lub wersji i faktycznie przechowuje swoje dane w innym miejscu (np.:/var/lib/mysql5/data/** w przeciwieństwie do /var/lib/mysql/** ). Widzisz więc, że katalog ma prawidłowe uprawnienia i własność a jednak nadal daje Errno 13, ponieważ apparmour/selinux nie pozwala na dostęp do niego.

Aby to zweryfikować, sprawdź dziennik systemowy pod kątem naruszeń bezpieczeństwa, ręcznie sprawdź konfigurację apparmor/selinux i/lub podszyj się pod użytkownika mysql i spróbuj przejść do podstawowego katalogu var, a następnie cd stopniowo, aż znajdziesz się w katalogu docelowym, i uruchom coś takiego touch aardvark && rm aardvark . Jeśli uprawnienia i własność są zgodne, a mimo to powyższe powoduje błąd dostępu, istnieje prawdopodobieństwo, że jest to problem ze strukturą bezpieczeństwa.

Powody Errno 39

Ten kod oznacza „katalog nie jest pusty”. Katalog zawiera niektóre ukryte pliki MySQL nic nie wie. W przypadku plików, które nie są ukryte, zobacz Errno 17. Rozwiązanie jest takie samo.

Powody Errno 17

Ten kod oznacza „plik istnieje”. Katalog zawiera plik MySQL, którego MySQL nie chce usuwać. Takie pliki mogły zostać utworzone przez SELECT ... INTO OUTFILE "filename"; polecenie gdzie filename nie miał ścieżki. W tym przypadku proces MySQL tworzy je w swoim bieżącym katalogu roboczym, który (testowany na MySQL 5.6 w OpenSuSE 12.3) jest katalogiem danych bazy danych , np. /var/lib/mysql/data/nameofdatabase .

Odtwarzalność:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]    

mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)

mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)

mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)

-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.

mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)

Przenieś plik(i) na zewnątrz (lub usuń, jeśli nie jest to konieczne) i spróbuj ponownie. Ponadto określ przede wszystkim, dlaczego zostały utworzone — może to wskazywać na błąd w jakiejś aplikacji . Albo gorzej:patrz poniżej...

AKTUALIZACJA:Błąd 17 jako flaga exploita

Stało się to w systemie Linux z zainstalowanym Wordpressem. Niestety klient miał ograniczenia czasowe i nie mogłem ani zobrazować dysku ani przeprowadzić prawdziwej rundy kryminalistycznej - przeinstalowałem całą maszynę, a Wordpress został zaktualizowany, więc mogę tylko powiedzieć, że jestem prawie pewni, że zrobili to za pomocą tej wtyczki .

Objawy :mysql katalog data zawierał trzy pliki z rozszerzeniem PHP. Czekaj, co?!? -- a wewnątrz plików znajdowała się większość kodu base64, który został przekazany do base64_decode , gzuncompress i [eval()][2] . Aha . Oczywiście były to tylko pierwsze próby, nieudane. Strona była dobrze i naprawdę pwn3d.

Więc jeśli znajdziesz plik w katalogu danych mysql, który powoduje błąd 17, sprawdź go za pomocą file użyteczność lub zeskanuj go programem antywirusowym. Lub wizualnie sprawdź jego zawartość. Nie zakładaj, że istnieje jakiś nieszkodliwy błąd.

(Nie trzeba dodawać, że aby wizualnie sprawdzić plik, nigdy nie klikaj go dwukrotnie ).

Ofiara w tym przypadku (miał przyjaciela, który „robił konserwację”) nigdy by się nie domyśliła, że został zhakowany, dopóki skrypt konserwacji/aktualizacji/cokolwiek nie uruchomił DROP DATABASE (nie pytaj mnie dlaczego – nie jestem pewien, nawet jeśli chcę wiedzieć ) i pojawił się błąd. Biorąc pod uwagę obciążenie procesora i komunikaty dziennika systemowego, jestem całkiem pewien, że host stał się farmą spamu.

Kolejny błąd 17

Jeśli rsync lub skopiuj między dwiema instalacjami MySQL tej samej wersji ale innej platformy lub systemu plików takie jak Linux lub Windows (co jest odradzane i ryzykowne, ale wielu to robi), a konkretnie z różnymi uwzględnianie wielkości liter ustawienia, możesz przypadkowo otrzymać dwie wersje tego samego pliku (dane, indeks lub metadane); powiedz Customers.myi i Customer.MYI . MySQL używa jednego z nich i nic nie wie o drugim (co może być nieaktualne i prowadzić do katastrofalnej synchronizacji). Podczas usuwania bazy danych, co zdarza się również w wielu mysqldump ... | ... mysql schematy tworzenia kopii zapasowych, DROP nie powiedzie się, ponieważ ten dodatkowy plik (lub te dodatkowe pliki) istnieje. Jeśli tak się stanie, powinieneś być w stanie rozpoznać przestarzałe pliki, które wymagają ręcznego usunięcia, od czasu pliku lub po tym, że ich schemat spraw różni się od większości innych tabel.

Znajdowanie katalogu danych

Ogólnie rzecz biorąc, katalog danych można znaleźć, sprawdzając my.cnf plik (/etc/my.cnf , /etc/sysconfig/my.cnf , /etc/mysql/my.cnf na Linuksie; my.ini w katalogu plików programu MySQL w systemie Windows), pod [mysqld] nagłówek, jako datadir .

Alternatywnie możesz poprosić o to sam MySQL:

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)