DriteStudioDRITESTUDIODRITESTUDIO
หน้าแรกบทความเกี่ยวกับเราติดต่อเรา
หน้าแรก
VPSเซิร์ฟเวอร์เสมือนประสิทธิภาพสูง พร้อมสิทธิ์ Root เต็มรูปแบบ
VPS ForexVPS เทรด Forex หน่วงต่ำพิเศษ สำหรับ EA และระบบเทรดอัตโนมัติ
เว็บโฮสติ้งโฮสติ้งพร้อมใช้งาน มี Plesk และ SSL ฟรี
โฮสติ้งเกมเซิร์ฟเวอร์รองรับเกมมากกว่า 20 เกมทั่วโลก เพียงเช่า VPS แล้วแจ้งเกมที่ต้องการติดตั้งกับเรา
เซิร์ฟเวอร์เฉพาะเซิร์ฟเวอร์เฉพาะระดับองค์กร พร้อม IPMI
ฝากวางเซิร์ฟเวอร์ฝากเซิร์ฟเวอร์ในศูนย์ข้อมูลมาตรฐานสากล
ความปลอดภัยWAF ระบบป้องกัน DDoS และ SOC เฝ้าระวังตลอด 24/7
รับทำเว็บไซต์ออกแบบและพัฒนาเว็บไซต์ด้วยเทคโนโลยีสมัยใหม่
บริการ SEOดันอันดับด้วยบทความ Backlink และ Technical SEO
สถานะระบบตรวจสอบสถานะระบบและความพร้อมใช้งาน
บทความเกี่ยวกับเราติดต่อเรา
0%
ปัญหาการไม่สามารถ Mount Filesystem ใน Linux
กลับหน้ารายการบทความ

ปัญหาการไม่สามารถ Mount Filesystem ใน Linux

แก้ปัญหา mount filesystem ไม่ได้ใน Linux สาเหตุจาก fstab UUID fsck และวิธีแก้ไข

Linux-20 สิงหาคม 2566-อัปเดต: 10 เมษายน 2569

Mount Filesystem ไม่ได้ใน Linux ต้องแก้ตรงไหน?

เซิร์ฟเวอร์บูตขึ้นมาแล้ว disk หาย mount point พัง หรือเจอข้อความ error แปลก ๆ ตอนสั่ง mount partition สถานการณ์แบบนี้เป็นปัญหาที่ผู้ดูแลระบบ Linux เจอบ่อยมาก และถ้าไม่รู้วิธีจัดการอย่างถูกต้อง อาจทำให้ข้อมูลสูญหายหรือเซิร์ฟเวอร์ใช้งานไม่ได้นานกว่าที่ควร บทความนี้จะพาไล่ทุกสาเหตุและวิธีแก้ไขอย่างเป็นขั้นตอน

สาเหตุหลักที่ Mount Filesystem ไม่สำเร็จ

ไฟล์ fstab ตั้งค่าผิดพลาด

ไฟล์ /etc/fstab คือหัวใจของการ mount อัตโนมัติตอนบูต ทุกบรรทัดในไฟล์นี้กำหนดว่า partition ไหนจะถูก mount ไปที่ mount point ใด หากมีการพิมพ์ผิดแม้แค่ตัวอักษรเดียว ผลที่ตามมาอาจรุนแรงถึงขั้นเซิร์ฟเวอร์บูตไม่ขึ้นเลย

กฎทองข้อแรกคือต้อง backup fstab ทุกครั้งก่อนแก้ไข:

sudo cp /etc/fstab /etc/fstab.bak

รูปแบบของแต่ละบรรทัดใน fstab:

# <device>                                <mount point>  <type>  <options>        <dump> <pass>
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data          ext4    defaults         0      2
/dev/sdb1                                  /backup        xfs     defaults,noatime 0      0

จากนั้นเปิดไฟล์ด้วย nano หรือ vi แก้ไขตามต้องการ และทดสอบด้วย mount -a ก่อนรีบูตเสมอ:

sudo mount -a

ถ้ามี error จะแสดงข้อความบอกว่าปัญหาอยู่ที่ partition ไหน

UUID กับ Device Name เลือกใช้อันไหนดี?

ปัญหาคลาสสิกที่เจอกันบ่อยคือการใส่ device name แบบ /dev/sdb1 ใน fstab โดยตรง ซึ่ง device name อาจเปลี่ยนทุกครั้งที่บูต ทางที่ถูกต้องคือใช้ UUID

ดู UUID ของทุก partition:

sudo blkid

ตัวอย่างผลลัพธ์:

/dev/sda1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"
/dev/sdb1: UUID="f9e8d7c6-b5a4-3210-fedc-ba9876543210" TYPE="xfs"

ดูโครงสร้าง disk และ partition ทั้งหมดแบบ tree:

lsblk

ตัวอย่างผลลัพธ์:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   50G  0 disk
├─sda1   8:1    0   49G  0 part /
└─sda2   8:2    0    1G  0 part [SWAP]
sdb      8:16   0  100G  0 disk
└─sdb1   8:17   0  100G  0 part /data

Filesystem เสียหายจากเหตุไม่คาดฝัน

สาเหตุที่พบบ่อยอีกอย่างคือตัว filesystem เสียหาย อาจเกิดจากไฟดับขณะกำลังเขียนข้อมูล disk มีปัญหาทางกายภาพ หรือ kernel panic ขณะทำงาน เมื่อ filesystem เสียหาย Linux จะปฏิเสธการ mount หรือ mount แบบ read-only

วิธีแก้ไขปัญหา Mount Filesystem ทีละขั้นตอน

ขั้นตอนที่ 1 ตรวจสอบ Error Message

ลอง mount ทุก entry ใน fstab เพื่อดู error:

sudo mount -a

mount partition เฉพาะตัวเพื่อ debug:

sudo mount /dev/sdb1 /data

ถ้าต้องการระบุ filesystem type:

sudo mount -t ext4 /dev/sdb1 /data

ขั้นตอนที่ 2 ซ่อม Filesystem ด้วย fsck

ข้อห้ามที่สำคัญที่สุดคือห้ามรัน fsck บน partition ที่กำลัง mount อยู่เด็ดขาด ต้อง unmount ก่อน:

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

สำหรับ XFS filesystem ใช้:

sudo xfs_repair /dev/sdb1

flag -y จะตอบ yes อัตโนมัติ ถ้าเป็น disk ที่มีข้อมูลสำคัญมาก แนะนำให้รันแบบ interactive:

sudo fsck /dev/sdb1

ขั้นตอนที่ 3 แก้ปัญหา Read-Only Filesystem

partition ถูก mount เป็น read-only โดยอัตโนมัติ ลอง remount:

sudo mount -o remount,rw /

ถ้า remount แล้วยังเป็น read-only อยู่ แปลว่า filesystem มีปัญหาจริง ๆ ต้องกลับไปใช้ fsck ซ่อมก่อน

จัดการปัญหา LVM ที่ Mount ไม่ได้

สำหรับเซิร์ฟเวอร์ที่ใช้ LVM อาจเจอ volume group ไม่ active หรือ logical volume หายไป:

# scan หา volume group ทั้งหมด
sudo vgscan

# activate ทุก volume group
sudo vgchange -ay

# ดูรายละเอียด logical volume
sudo lvdisplay

# mount logical volume
sudo mount /dev/vgname/lvname /data

ตรวจสุขภาพ Disk ด้วย SMART

ถ้า disk มีปัญหา mount บ่อย ๆ ควรเช็ค SMART status:

# ติดตั้ง smartmontools
sudo apt install smartmontools    # Debian/Ubuntu
sudo yum install smartmontools    # RHEL/CentOS

# ตรวจสุขภาพ disk
sudo smartctl -a /dev/sda

# ดูสถานะสุขภาพแบบสรุป
sudo smartctl -H /dev/sda

ดูค่า Reallocated Sector Count และ Current Pending Sector หากมีค่าสูงผิดปกติ ควรเตรียมเปลี่ยน disk และย้ายข้อมูลก่อนที่จะสายเกินไป

โครงสร้างพื้นฐานที่วางใจได้ลดปัญหา Filesystem

ปัญหา filesystem หลายอย่างมีต้นตอจาก hardware ที่ไม่น่าเชื่อถือ การเลือกใช้ VPS จาก DriteStudio ที่ใช้ SSD คุณภาพสูงพร้อมระบบ monitoring ช่วยลดโอกาสเจอปัญหาเหล่านี้ได้ตั้งแต่ต้น

สำหรับงานที่ต้องการ storage ขนาดใหญ่และ performance สูง Dedicated Server จาก DriteStudio มี RAID configuration ให้เลือกตามความต้องการ พร้อมระบบรักษาความปลอดภัยที่ช่วยแจ้งเตือนก่อน disk จะมีปัญหา

คำถามที่พบบ่อย (FAQ)

fsck กับ mount -a ต่างกันอย่างไร?

mount -a ใช้สำหรับทดสอบ mount ทุก partition ตาม fstab เพื่อดูว่ามี error ตรงไหน ส่วน fsck ใช้สำหรับซ่อม filesystem ที่เสียหายจริง ๆ ควรใช้ mount -a ตรวจสอบก่อน แล้วค่อยใช้ fsck เมื่อพบว่า filesystem มีปัญหา

ทำไมต้องใช้ UUID แทน device name?

เพราะ device name เช่น /dev/sdb1 อาจเปลี่ยนได้ทุกครั้งที่บูตหรือเพิ่มถอด disk แต่ UUID ผูกกับ partition โดยตรงและไม่เปลี่ยนแปลง การใช้ UUID ใน fstab จึงปลอดภัยกว่ามาก

mount แล้วขึ้น read-only แก้ยังไง?

ลอง remount ด้วย sudo mount -o remount,rw / ก่อน ถ้ายังเป็น read-only อยู่ แสดงว่า filesystem เสียหาย ต้อง unmount แล้วใช้ fsck ซ่อมก่อนจึงจะ mount แบบ read-write ได้

LVM volume group หายไปต้องทำอย่างไร?

ใช้คำสั่ง sudo vgscan เพื่อ scan หา volume group ทั้งหมด ตามด้วย sudo vgchange -ay เพื่อ activate ถ้ายังไม่เจอ ให้ตรวจสอบว่า disk ที่เป็น physical volume ยังเชื่อมต่ออยู่หรือไม่

สรุป

ปัญหา mount filesystem ใน Linux ส่วนใหญ่แก้ได้ด้วยการตรวจสอบ fstab ให้ถูกต้อง ใช้ UUID แทน device name และซ่อม filesystem ด้วย fsck เมื่อจำเป็น สิ่งสำคัญที่สุดคือ backup ก่อนแก้ไขทุกครั้ง ทดสอบด้วย mount -a ก่อนรีบูต และตรวจสอบสุขภาพ disk เป็นประจำ หากทำตามขั้นตอนเหล่านี้ ปัญหา filesystem จะไม่ใช่เรื่องน่ากลัวอีกต่อไป

แชร์บทความ:
ดูบทความเพิ่มเติม
D

DriteStudio | ไดรท์สตูดิโอ

ผู้ให้บริการโครงสร้างพื้นฐานดิจิทัลสำหรับ VPS เว็บโฮสติ้ง และบริการฝากวางเซิร์ฟเวอร์ในประเทศไทย

ดำเนินการโดย บริษัท คราฟต์ อินเตอร์เทค (ประเทศไทย) จำกัด

© 2026 บริษัท คราฟต์ อินเตอร์เทค (ประเทศไทย) จำกัด สงวนลิขสิทธิ์

นโยบายความเป็นส่วนตัวข้อกำหนดการให้บริการสถานะระบบ