Soru MySQL: Veritabanı bırakılırken hata oluştu (errno 13; errno 17; errno 39)


Veritabanını düşüremedim:

mysql> veritabanı mydb bırakın;
ERROR 1010 (HY000): Veritabanı bırakılırken hata oluştu (rmdir './mydb', errno: 39)

Mysql ağacında db / mydb dizini var, ancak tablo yok:

# ls -l db / mydb
-rw-rw ---- mysql mysql HIS_STAT.MYD
-rw-rw ---- mysql mysql HIS_STAT.MYI

Ne yapmalıyım?


44
2017-08-30 12:37


Menşei


İzin konusu gibi görünüyor. Tam gönderebilir misin ls -l çıktı? - Chris Henry
@ Chris Henry: Soruyu # ls -l mydb sonucuyla güncelledim - Philippe Blayo


Cevaplar:


Errno 13

MySQL'in ana dizininde yazma izni yoktur. mydb klasör bulunur.

İle kontrol edin

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

Linux'ta bu, MySQL ve AppArmor / SELinux paketlerini karıştırıp eşleştirdiğinizde de gerçekleşebilir. Ne olur ki AppArmor, mysqld’in /path/to/data/dirve orada tam R / W'ye izin verir, fakat MySQLd farklı bir dağıtımdan veya yapıdan gelir ve aslında verilerini saklar. başka yerde (Örneğin.: /var/lib/mysql5/data/** aksine /var/lib/mysql/**). Gördüğünüz şey, dizinin Doğru izinler ve sahiplik ve yine de yine de Errno 13'ü veriyor, çünkü apparmor / selinux ona erişime izin vermiyor.

Doğrulamak için, güvenlik ihlalleri için sistem günlüğünü kontrol edin, apparmor / selinux yapılandırmasını manuel olarak denetleyin ve / veya mysql kullanıcısını taklit edin ve taban var dizinine gitmeyi deneyin, sonra hedef dizinde olana kadar aşamalı olarak cd yapın ve touch aardvark && rm aardvark. İzinler ve sahiplik eşleşirse ve yukarıdakiler bir erişim hatası verirse, bunun bir güvenlik çerçevesi sorunu olması olasılığı vardır.

Errno 39

Bu kod "dizin boş değil" anlamına gelir. Dizin bazı içerir gizli dosyaları MySQL hakkında hiçbir şey bilmiyor. Gizli olmayan dosyalar için bkz. Errno 17. Çözüm aynıdır.

Errno 17

Bu kod "dosya var" anlamına gelir. Dizin MySQL'in silme hakkında hissetmediği bazı MySQL dosyalarını içerir. Bu gibi dosyalar bir SELECT ... INTO OUTFILE "filename"; komuta nerede filename yolu yoktu. Bu durumda, MySQL işlemi onları mevcut çalışma dizininde oluşturur (OpenSuSE 12.3 üzerinde MySQL 5.6 üzerinde test edilmiştir) veritabanının veri dizini, Örneğin. /var/lib/mysql/data/nameofdatabase.

Tekrarlanabilirlik:

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)

Dosyayı (dosyaları) dışa taşıyın (veya gerekmiyorsa silin) ​​ve tekrar deneyin. Ayrıca, ilk olarak neden oluşturulduklarını belirleyin - bazı uygulamalarda bir hatayı işaret edebilir. Ya da daha kötüsü: aşağıya bakın ...

GÜNCELLEME: exploit bayrağı olarak Hata 17

Bu, Wordpress yüklü bir Linux sisteminde oldu. Ne yazık ki müşteri zaman kısıtlamaları altındaydı ve ben diski görüntüleyemedim ya da gerçek bir adli tıp işi yapamadım - tüm makineyi yeniden yükledim ve Wordpress bu süreçte güncellendi, bu yüzden sadece neredeyse Yaptıklarını kesin bu eklenti.

belirtiler: the mysql veri dizini uzantısı PHP ile üç dosya içeriyordu. Bir dakika ne?!? - ve dosyaların içine aktarılan bir dizi base64 kodu vardı. base64_decode, gzuncompress ve [eval()][2]. Aha. Elbette bunlar sadece ilk denemeler, başarısız olanlardı. Site iyi ve gerçekten pwn3d olmuştu.

Yani mysql verilerinizde bir dosya bulursanız, bu da bir Hata 17'ye sebep olur. ile kontrol et file Yarar ya da bir antivirüs ile tarayın. Veya içeriğini görsel olarak inceleyin. Belli bir hata için var olduğunu düşünmeyin.

Bu davadaki mağdur (bazı arkadaşlarının "bakımını yapması" vardı) hiçbir zaman bir bakım / güncelleme / komut dosyası çalıştırılana kadar saldırıya uğradığını tahmin edemezdi. DROP DATABASE (bana neden sorma - bilmek istediğimden emin değilim) ve bir hata var. CPU yükünden ve syslog mesajlarından, ev sahibinin bir spam grubu haline gelmesi konusunda oldukça olumluyım.

Yine başka bir hata 17

Eğer sen rsync veya aynı sürümün iki MySQL kurulumu arasında kopyalama farklı platform veya dosya sistemleri Linux veya Windows gibi (ki cesaret kırılır ve risklidir, fakat çoğu yine de bunu yapar) ve özellikle farklıdır büyük küçük harf duyarlılığı Ayarlar, yanlışlıkla sonuçlanabilir iki versiyon aynı dosyadan (veri, dizin veya meta veri); söylemek Customers.myi ve Customer.MYI. MySQL bunlardan birini kullanır ve diğeri hakkında hiçbir şey bilmez (ki bu güncel olmayabilir ve felakete neden olabilir). Veritabanını bırakırken, aynı zamanda birçok mysqldump ... | ... mysql yedekleme şemaları DROP Bu ekstra dosya (veya bu fazladan dosyalar) var. Böyle bir durumda, dosya zamanından el ile silinmesi gereken eski dosyaları tanıyabilir veya vaka şeması diğer tabloların çoğundan farklı olabilir.

Veri-dir bulma

Genel olarak, veri dizinini inceleyerek veri dizinini bulabilirsiniz. my.cnf dosya (/etc/my.cnf, /etc/sysconfig/my.cnf, /etc/mysql/my.cnf Linux'ta; my.ini altında Windows'daki MySQL program dosyaları dizininde) [mysqld] başlık olarak datadir.

Alternatif olarak MySQL'e kendiniz sorabilirsiniz:

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

87
2017-08-30 13:06



Başlıklar için teşekkürler @ xk0der (ama aslında bir yorum Yap). Hakkında öneri my.cnf cevaba ekledi. Hata 13, burada sorun giderme için yararlı olabilir, bu yüzden bende kalmaya karar verdim. - LSerni
Benim durumumda, OUTFILE kullanarak bir tablonun dökümünü almaya çalışıyordum ve bu dosya veritabanı adı altında veri dizinine kaydedildi. Bu dosyayı silerek çözüldü. - Taranjeet


Benim durumumda 'lower_case_table_names' parametresi nedeniyle oldu.

Lower_case_table_names parametresiyle büyük harfli isimler içeren veritabanlarını bırakmaya çalıştığımda atılan 39 numaralı hata etkindi.

Bu, küçük harf parametresi değişikliklerini önceki duruma geri döndürerek sabitlenir.


23
2018-03-10 12:59



Doğru. Bu ayar nedeniyle olabilir. BU ayar, ayarın doğru bir çözüm değil, bir uzlaşma IMHO olduğunu geri almak. - Vikas B
Bu benim problemimi çözdü. Geri alabilir, veritabanlarını silebilir ve geri alabilirsin ... - c4k
evet, benim de sebebim buydu - Ashish Ratan
sorunumu çözdüm - Charles-Antoine Fournel
Bu benim problemimi çözmemde bana yardımcı oldu - hemantgp


Basitçe / opt / lampp / var / mysql adresine gidin

Datavase adınızı burada bulabilirsiniz. Bu klasörü aç. İçindeki herhangi bir dosyayı kaldır

Şimdi phpmyadmin'e gel ve o veritabanını bırak.


4
2017-11-09 17:21





Gelince ERRORCODE 39Kesinlikle diskteki fiziksel tablo dosyalarını silebilirsiniz. konum, işletim sisteminizin dağıtımına ve kurulumuna bağlıdır. Debian'da tipik olarak / var / lib / mysql /veri tabanı ismi/ Yani bir:

rm -f /var/lib/mysql/<database_name>/

Ardından veritabanını seçim aracınızdan veya komutu kullanarak bırakın:

DROP DATABASE <database_name>

2
2018-05-03 07:50



Bu benim için çalışıyor. Dosyaları kaldırmadan önce, önce mysql sunucusunu durdurun (servis mysql stop), sonra dosyaları kaldırın ve tekrar başlayın. Sonunda mysql ve DROP db giriş yapın. - bakalov
Çok, çok yararlı, teşekkürler, beni kurtar, basit ve doğrudan. - Ariane Martins Gomes Do Rego


linux'da, "/ var / lib / mysql" ye sağ tuşla gidin ve (adminstrator olarak açın), mysql klasörü içindeki veritabanı adınıza karşılık gelen klasörü bulun ve silin. bu kadar. Veritabanı düştü.


-2
2017-07-13 08:00