插上U盘却挂载不了，这大概是Linux新手和老手都会遇到的场景。我在CentOS 7上折腾移动硬盘和U盘挂载时，踩过不少坑，尤其是exFAT格式的盘，系统默认根本不认，更别提直接mount了。这篇就把FAT32和exFAT两种格式的挂载方法、背后的原理、以及那些容易让人卡壳的细节一次讲透，希望能帮你少走弯路。
先交代一下适用场景：这篇文章针对的是CentOS 7（包括7.x全系列小版本），如果你用的是CentOS 8/9、Rocky Linux、AlmaLinux，大部分命令通用，但yum和dnf的差异需要你自己留意。适合的人包括：刚接触Linux的运维新手、需要定期在服务器上拷贝数据的技术人员、玩树莓派或开发板想挂载U盘的爱好者。内容不需要你有很深的Linux基础，但至少得知道怎么打开终端、怎么使用vim编辑文件。
1. 挂载前的准备工作：先认清自己的U盘是什么格式
很多人一上来就执行mount /dev/sdb1 /mnt，结果报错，然后就懵了。其实挂载失败的第一原因，不是命令不对，而是你根本没搞清U盘是什么文件系统。所以第一步不是急着挂载，而是先做两件事：插上设备，然后查看系统识别到的设备信息。
1.1 为什么CentOS 7对FAT32和exFAT的态度完全不同
这里要先说清楚一个概念：FAT32和exFAT虽然都出自微软，但它们在Linux内核里的待遇天差地别。FAT32是Linux内核自带的文件系统模块，叫vfat，RHEL/CentOS 7的默认内核里就直接编译进去了，所以插上FAT32格式的U盘，理论上是可以直接挂载的。而exFAT是微软专门为U盘和大容量SD卡设计的新一代文件系统，专利和授权问题导致Linux内核一直没把它合入主线，直到kernel 5.4之后，exFAT才正式成为内核原生支持的模块。
CentOS 7默认用的是3.10版本的内核（后续小版本可能有更新，但主要在bug fix上），远远达不到5.4，所以系统本身完全不认识exFAT。这就是为什么同样一个U盘，FAT32格式插上去能用，exFAT格式插上去系统毫无反应，blkid甚至都读不出文件系统类型。
1.2 用lsblk和blkid定位设备节点
准备工作的核心，就是要确认U盘对应的设备节点是/dev/sdb还是/dev/sdc，以及上面的分区是/dev/sdb1还是别的。最稳妥的做法是插上U盘前先执行一次lsblk，插上之后再执行一次，对比两次输出多出来的那个设备就是你的U盘。
# 插U盘之前 lsblk # 插上U盘之后 lsblk正常情况下你会看到类似这样的输出：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 40G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 39G 0 part └─centos-root 253:0 0 39G 0 part / sdb 8:16 1 28.7G 0 disk └─sdb1 8:17 1 28.7G 0 part看到sdb了吗？RM那一列显示1，说明它是可移动设备。sdb1就是U盘上的第一个分区，之后挂载基本就是针对这个分区操作。lsblk偶尔会抽风，比如U盘上有多个分区，或者分区表损坏，这时候就用blkid来看得更清楚：
blkidblkid会输出每个块设备的UUID和文件系统类型，比如：
/dev/sdb1: UUID="A1B2-C3D4" TYPE="vfat" PARTUUID="e7d0f1a2-04"看到TYPE="vfat"就说明这个U盘是FAT32格式，可以直接挂载；如果是TYPE="exfat"，那就得先装驱动，后面第4节会详细讲。如果用blkid什么都读不出来，那U盘有可能是NTFS、ext4这类格式，或者是没有格式化过的裸盘，需要进一步用parted或fdisk确认。
提示：判断U盘设备节点，最靠谱的方法是看大小和RM标记。千万不要凭感觉去
mount /dev/sdc1，万一挂错盘，数据出问题就麻烦了。
2. FAT32和exFAT的区别，以及为什么CentOS默认不支持exFAT
在动手操作之前，花三分钟把FAT32、exFAT、NTFS这三者的关系理清楚，后面遇到问题你就知道该往哪个方向排查了。
2.1 FAT32、exFAT、NTFS三者的定位差异
FAT32是1996年前后随Windows 95 OSR2推出的文件系统，它最大的优势是兼容性极好，从数码相机到老式电视、从游戏机到车载音响，几乎只要是带USB接口的设备都认识FAT32。但它的缺点也很致命：单个文件不能超过4GB，单个分区理论最大只能到2TB（实际上Windows格式化时建议不超过32GB）。所以当你需要在U盘上拷一个5GB的系统镜像或者高清视频时，FAT32直接罢工。
exFAT就是微软为了解决这个问题推出的，2006年随Windows CE 6.0发布，单文件大小上限达到了惊人的16EB（实际上受限于存储介质），分区大小也没了实际限制，专门为U盘、SD卡这类闪存介质优化。缺点是兼容性不如FAT32，老设备不一定认识，而且一直有专利和授权方面的争议。
NTFS则是Windows的主力文件系统，支持权限控制、日志、压缩、加密等一堆高级特性，但Linux下读写NTFS得靠ntfs-3g这个FUSE驱动，而且在U盘这种闪存介质上使用NTFS，如果没有安全弹出就直接拔盘，丢数据的风险比FAT32/exFAT高不少。
三者的对比，我用一张表来总结：
| 文件系统 | 单文件大小上限 | 分区大小上限 | Linux内核原生支持 | 典型使用场景 |
|---|---|---|---|---|
| FAT32 | 4GB | 2TB | 支持（vfat） | 小文件拷贝、老设备/跨设备共用 |
| exFAT | 16EB | 128PB | 5.4+内核原生，旧内核需第三方驱动 | 大文件拷贝、U盘/SD卡日常使用 |
| NTFS | 16EB | 256TB | 不支持原生读写，需ntfs-3g | Windows系统盘、跨平台大文件交换 |
2.2 exFAT的专利与内核模块问题
为什么CentOS 7的内核不支持exFAT？其实不只是CentOS，整个RHEL 7系列、Ubuntu 18.04及更早版本，默认都不支持exFAT。根本原因在于微软对exFAT持有专利，并采用授权方式允许使用，Linux内核如果直接内置exFAT支持，可能会面临专利诉讼风险。所以内核社区一直拒绝将exFAT合入主线，直到2019年微软宣布将exFAT相关专利纳入"承诺不对Linux内核使用者主张权利"的协议中，exFAT才在Linux kernel 5.4被正式接纳。
CentOS 7的3.10内核太老，想用exFAT就只能靠用户态方案解决，主流的做法有两个：一个是fuse-exfat，通过FUSE（Filesystem in Userspace）机制，在内核外层运行一个用户态程序来读写exFAT分区；另一个是exfatprogs，配合内核模块exfat使用，但CentOS 7的旧内核根本没有这个模块，所以基本用不上exfatprogs。后面第4节会详细讲fuse-exfat的安装和配置。
注意：有一种说法是"CentOS 7可以通过升级内核到5.4+来原生支持exFAT"，这个方案理论上可行，但对生产服务器来说风险太大，不建议为了挂一个U盘去动内核。用fuse-exfat就够了，性能虽然有点损耗，但对于U盘和移动硬盘这种IO场景来说，完全够用。
3. 挂载FAT32格式U盘的完整过程
FAT32在CentOS 7上的挂载相对简单，但因为用户和权限的问题，很多人还是会遇到"挂上了但写不进去"或"中文乱码"的情况。这部分我把每一步细节都讲清楚。
3.1 直接mount命令挂载vfat分区
假设你已经确认U盘设备节点是/dev/sdb1，先创建一个挂载点，然后执行mount：
mkdir -p /mnt/usb mount -t vfat /dev/sdb1 /mnt/usb cd /mnt/usb ls -l正常情况下你就能看到U盘里的文件了。但是！这里有一个很容易被忽略的问题：当你直接以root身份挂载vfat分区，并且没有任何额外参数时，FAT32文件系统本身不支持Unix文件权限，所以内核会按照默认规则给你设置挂载点的权限，通常是root:root，权限为755或者更严格。这时候如果你用普通用户去写U盘，就会提示"Permission denied"。
我的建议是，挂载FAT32时显式指定uid、gid和umask，这样就不用来回切换用户了。比如以uid为1000的用户挂在U盘：
mount -t vfat -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/usbuid和gid可以通过id命令查看，umask=022代表创建的文件权限是644，目录权限是755，也就是说除了文件所有者可以写，其他用户只能读和执行。如果你希望所有用户都能读写，可以用umask=000。还有更省事的写法，直接用dmask和fmask分别控制目录和文件的权限掩码：
mount -t vfat -o uid=1000,gid=1000,dmask=000,fmask=111 /dev/sdb1 /mnt/usbdmask=000让目录变成777，fmask=111让文件变成666，这是一般U盘拷贝场景下比较省心的组合。
3.2 解决中文乱码、权限和umask问题
中文乱码是FAT32挂载的老生常谈。原因是FAT32在Windows下存储文件名时用的是本地编码（中文Windows下通常是GBK/CP936），而Linux的vfat模块默认使用UTF-8编码去解析，两边对不上，所以显示成乱码。解决办法是挂载时指定iocharset=utf8或codepage=936：
mount -t vfat -o iocharset=utf8,uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/usb如果你的系统locale是en_US.UTF-8（CentOS 7默认就是这个），加上iocharset=utf8就够了。如果你的系统locale比较特殊，可能还需要加上codepage=936。不过我自己实测下来，大多数场景iocharset=utf8都能解决乱码问题，因为内核的NLS层会把文件名从GBK转成UTF-8。其实更彻底的方案是修改系统的locale，但为了一个U盘去改locale动静太大，不如挂载参数一行搞定。
权限问题的根源在于，FAT32本身没有Unix权限位的概念，所有权限都是内核在挂载时虚拟出来的。所以不要试图用chmod去修改FAT32分区里文件的权限，那是徒劳的，挂载参数里的umask才是真正的控制手段。
3.3 FAT32单文件4GB限制的实际影响
这部分可以说是FAT32最大的硬伤，也常常是用户"明明U盘格式是FAT32，但拷个大文件就报错"的原因。FAT32的文件分配表用32位记录簇号，单个文件大小理论上限是4GB减1字节，所以只要你拷的文件超过4GB，无论空间多充足，系统都会提示"文件过大"或"No space left on device"。
这个限制对服务器运维来说影响挺大的。比如你要把CentOS 7的ISO镜像（通常4GB左右）或数据库备份文件拷到U盘上，FAT32直接不给用。这时候有两个选择：一是把U盘格式化成exFAT（前提是系统能挂载exFAT），二是分割文件或用压缩包分卷。我的建议是从根上解决，把U盘做成exFAT格式，专门对付大文件拷贝。
4. 挂载exFAT格式移动硬盘的完整过程
进入正题，这是CentOS 7上最容易卡住的地方。exFAT格式的移动硬盘或U盘，插上CentOS 7之后系统是没有任何反应的，lsblk能看到设备，但blkid读不出文件系统类型，直接mount会报"unknown filesystem type 'exfat'"。下面讲怎么搞定。
4.1 安装exfat驱动：yum源方案与源码编译方案
CentOS 7上最便捷的安装方式是用EPEL仓库外加Nux Dextop或RPM Fusion这类第三方仓库来安装fuse-exfat。但是需要注意的是，EPEL本身不带fuse-exfat，需要额外添加源。我在实际使用中比较推荐的是加一个nux-dextop仓库，里面包含了fuse-exfat和exfat-utils。
先安装EPEL：
yum install -y epel-release然后添加Nux Dextop源（以CentOS 7为例）：
rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm接着安装fuse-exfat：
yum install -y fuse-exfat exfat-utils安装完成后，先别急着挂载，执行一下modprobe fuse确认FUSE模块加载正常。如果/dev/fuse设备节点不存在，可以手动创建：
modprobe fuse ls -l /dev/fuse如果你的服务器不能访问外网，或者不想添加第三方仓库，那就只能源码编译了。编译需要先安装依赖：
yum install -y gcc make fuse fuse-devel pkgconfig然后从GitHub上下载fuse-exfat源码：
git clone https://github.com/relan/exfat.git cd exfat autoreconf --install ./configure make make install编译安装后，fuse-exfat会安装到/usr/local/bin下，系统需要能通过mount.exfat-fuse或mount -t exfat找到对应的挂载工具。如果直接mount -t exfat报错找不到，可以用完整路径/usr/local/bin/mount.exfat-fuse /dev/sdb1 /mnt/usb来挂载。
注意：源码编译的fuse-exfat，在
mount -t exfat时依赖/sbin/mount.exfat这个符号链接。如果你不想折腾符号链接，最省事的方法还是直接用yum装，反正版本也够用。
4.2 挂载exFAT分区的具体命令与验证
安装完驱动后，挂载exFAT分区就很简单了：
mkdir -p /mnt/exfat mount -t exfat /dev/sdb1 /mnt/exfat如果不出意外，这个时候就能正常访问了。但我强烈建议你也加上uid、gid和umask参数，理由和FAT32一样，exFAT同样不支持Unix权限：
mount -t exfat -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/exfat挂载成功之后，验证一下文件系统类型和挂载状态：
df -hT /mnt/exfat mount | grep exfatdf -hT会显示类似/dev/sdb1 exfat 28G 10G 18G 36% /mnt/exfat的输出，看到文件系统类型是exfat，说明一切正常。再测试一下读写，写入一个大文件试试：
dd if=/dev/zero of=/mnt/exfat/test.img bs=1M count=1024这个命令会在U盘上生成一个1GB的测试文件，用来验证exFAT驱动能不能正常处理大文件写入。写完记得sync一下再删除测试文件：
sync rm /mnt/exfat/test.img4.3 fuse-exfat与exfatprogs两个方案怎么选
不少人上网搜到"exfatprogs"这个工具，然后跑来问我哪个好。先解释一下：exfatprogs是2019年后随新内核推出的exFAT工具集，包含mkfs.exfat、fsck.exfat等，但它需要配合内核自带的exfat模块使用，而CentOS 7的3.10内核根本没有这个模块。所以对CentOS 7用户来说，exfatprogs基本派不上用场。
fuse-exfat则是老牌方案，它由两个部分组成：一个是exfat-fuse，负责通过FUSE接口挂载和读写exFAT分区；另一个是exfat-utils，里面有mkexfatfs、exfatlabel等工具。它的优点是不依赖内核版本，只要内核支持FUSE（CentOS 7默认支持），就能正常工作。缺点是性能上比原生内核模块差一些，毕竟多了一层用户态和内核态的数据拷贝，但具体到U盘和移动硬盘的IO场景，这个差距基本感知不到。
所以结论很明确：CentOS 7上用fuse-exfat，没得选，也别纠结。
| 方案 | 适用内核 | 安装方式 | 优点 | 缺点 |
|---|---|---|---|---|
| fuse-exfat | 3.x通用 | yum/源码编译 | 兼容性好，不依赖内核版本 | 有FUSE层开销，性能略低 |
| exfatprogs + 内核exfat模块 | 5.4+ | yum（新版本系统） | 内核原生，性能好 | CentOS 7用不了 |
5. 开机自动挂载：fstab配置与常见坑
服务器上用好U盘或移动硬盘，如果每次重启都要手动mount一次，那实在太不专业了。配置/etc/fstab实现开机自动挂载，是运维必备技能，但这里面的坑也不少。
5.1 用UUID代替设备名的原因
很多刚接触Linux的人会写成这样：
/dev/sdb1 /mnt/usb vfat defaults 0 0表面看起来没问题，但隐患很大。因为Linux的磁盘设备名（/dev/sdb、/dev/sdc）不是固定的，取决于系统在启动时检测到设备的顺序。今天你的U盘是/dev/sdb，明天插了另一个移动硬盘，它就变成/dev/sdc了。开机自动挂载时如果设备名对不上，系统就会挂载失败，甚至可能直接进入emergency mode。
解决办法是用UUID（全局唯一标识符）。blkid不管文件名怎么变，UUID是跟着分区走的，不会变。所以先用blkid查到U盘分区的UUID，然后写进fstab。
5.2 fstab配置示例与测试挂载
以FAT32为例，假设你的U盘UUID是A1B2-C3D4，要挂载到/mnt/usb，fstab里的写法是：
UUID=A1B2-C3D4 /mnt/usb vfat uid=1000,gid=1000,umask=022,iocharset=utf8 0 0exFAT的话，文件系统类型写exfat：
UUID=A1B2-C3D4 /mnt/exfat exfat uid=1000,gid=1000,umask=022 0 0写完fstab之后，千万别直接重启，先执行一次测试挂载：
mount -amount -a会按照fstab配置把里面所有还没挂载的设备都挂载一遍，如果配置有误，当场就会报错，这样你可以及时改回来，不至于等到重启后系统卡在挂载环节。测试通过后，可以再执行umount /mnt/usb，然后执行mount -a确认能自动挂载上。
5.3 重启后失效/挂载失败的排查思路
fstab配置看起来很完美，但重启后U盘还是没挂载，这种情况我遇到过很多次。排查思路按以下顺序来：
第一，确认UUID是否正确。U盘重新格式化后UUID会变，fstab里的UUID必须用blkid重新查过的最新值。第二，确认挂载点目录存在。如果/mnt/usb目录不存在，挂载肯定失败。第三，看启动日志。运行journalctl -b | grep -i mount或dmesg | grep -i ext4/exfat/fat，找到对应的错误信息。第四，确认U盘在系统启动时是否已经被识别。如果U盘插在USB 3.0口上，有些老主板的BIOS在开机自检阶段没有初始化USB控制器，系统启动完成后内核才识别到设备，这时候fstab即使配置正确也会挂载失败。
针对第四种情况，我建议用systemd的mount单元配合nofail选项。fstab的第四列加上nofail，表示即使设备不存在也不要阻塞系统启动：
UUID=A1B2-C3D4 /mnt/usb vfat uid=1000,gid=1000,umask=022,iocharset=utf8,nofail 0 0加nofail后，重启时U盘没插上系统也能正常启动，插上了就会自动挂载，这算是我踩过几次坑之后比较稳妥的配置方案。
注意：fstab第5、6列的0 0，代表不需要做dump备份和开机自检。U盘这种移动设备千万别设置成1，否则开机自检时如果分区状态异常，系统会一直卡在fsck阶段。
6. 常见问题与排查技巧实录
这部分是把我在实际运维中遇到的高频问题整理出来，每个问题都附上了排查命令和解决办法，建议收藏备用。
6.1 U盘插上没反应，dmesg看不到设备
插上U盘后，lsblk看不到新设备，dmesg也没有任何输出，这种情况大概率不是文件系统的问题，而是硬件层没识别到。先确认USB接口是不是好的，换个口试试，台式机优先插机箱后面板。然后执行lsusb，看有没有出现新的USB设备。如果lsusb能看到但lsblk看不到，可能是USB存储驱动没加载：
modprobe usb-storage dmesg | tail -20另外，如果在虚拟机里测试，记得检查虚拟机设置里是否启用了USB控制器，并且把U盘从宿主机切换到虚拟机。
6.2 挂载后中文文件名全是乱码
这个问题在前面提过，解决起来就是挂载参数加iocharset=utf8：
umount /mnt/usb mount -t vfat -o iocharset=utf8,uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/usb如果加了iocharset=utf8还是乱码，可以试试codepage=936或者两者一起加。理论上FAT32在挂载时指定codepage=936是为了让vfat模块正确处理FAT短文件名中的GBK编码字符，而iocharset=utf8则是让NLS层在文件名转换时输出UTF-8。两个参数一起用，兼容性会更好。
6.3 移动硬盘识别为/dev/sdb，但mount报错
如果mount报错wrong fs type, bad option, bad superblock on /dev/sdb1，先不要急着格式化，先确认分区表类型。老移动硬盘可能是MBR分区表，GPT分区表在新硬盘上更常见。可以用parted /dev/sdb print查看：
parted /dev/sdb print或者用fdisk -l /dev/sdb看分区信息。有些移动硬盘出厂时没有分区表，整块盘就是一个FAT32/exFAT文件系统，这时候你应该直接挂载/dev/sdb而不是/dev/sdb1：
mount -t exfat /dev/sdb /mnt/exfat还有一种情况是移动硬盘有多个分区，比如一个EFI启动分区加一个数据分区，你得挂载数据分区（通常是容量最大的那个），而不是第一个分区。
6.4 遇到只读文件系统怎么办
U盘或移动硬盘挂载后只能读不能写，首先用mount看挂载选项里有没有ro标志。如果有，说明挂载时指定了只读，重新挂载成读写即可：
mount -o remount,rw /mnt/usb如果挂载选项里确实是rw，但写入仍然报Read-only file system，那就需要检查文件系统本身是否有错误。FAT32可以使用fsck.vfat检查修复，exFAT可以使用fsck.exfat（需要exfat-utils）检查：
umount /mnt/usb fsck.vfat -a /dev/sdb1 fsck.exfat /dev/sdb1另外，还有一小部分U盘本身有写保护开关，或者是物理损坏导致的只读，这种情况软件手段救不了，直接换盘。
6.5 想把exFAT改成FAT32或反过来
有些老设备不认exFAT，需要把U盘改成FAT32；反过来，U盘经常拷大文件，又得从FAT32改成exFAT。在Linux下重新格式化U盘，命令如下。注意，格式化会清空U盘所有数据，操作前确认数据已备份。
格式化FAT32：
mkfs.vfat -F 32 -n MyUSB /dev/sdb1格式化exFAT（需要exfat-utils或exfatprogs）：
mkfs.exfat -n MyUSB /dev/sdb1格式化时分区号要选对，如果U盘之前没有分区，可以直接对/dev/sdb整个设备执行mkfs.vfat。想稳妥一点，先用fdisk删掉旧分区重建一个，再格式化。另外，Windows下格式化exFAT时默认的簇大小是128KB还是256KB看容量而定，Linux下mkfs.exfat默认簇大小是自动选择的，不需要特别干预。
6.6 常用排查命令速查表
我整理了一个表格，方便你在遇到问题的时候快速定位：
| 问题现象 | 优先使用的命令 | 排查方向 |
|---|---|---|
| 设备看不到 | lsusb、dmesg | tail | USB控制器、驱动加载 |
| 能看到但mount报unknown filesystem | blkid、mount -t vfat/exfat | 文件系统类型、驱动是否安装 |
| 中文乱码 | mount -o iocharset=utf8 | NLS编码转换 |
| 读写权限受限 | mount -o uid/gid/umask | FAT/exFAT无Unix权限 |
| 写入报错或文件过大 | df -hT、ls -lh | 分区空间、单文件大小限制 |
| 开机不自动挂载 | journalctl -b | grep -i mount | fstab配置、UUID、设备识别时机 |
| 只读文件系统 | mount、fsck.vfat、fsck.exfat | 挂载选项、文件系统损坏 |
| 文件系统损坏 | fsck.vfat -a、fsck.exfat | 异常拔盘、坏道 |
7. 一些需要养成的习惯和盘外招
写到这里，关键技术点基本都覆盖了，最后分享几个我在实际使用中积累的小习惯和"盘外招"，有些是花钱买教训总结出来的，拿去吧。
第一，拔U盘前一定要umount，不要直接物理拔掉。Linux有page cache，写入的数据可能还缓存在内存里没有落盘，直接拔会造成文件系统损坏。养成习惯，先sync再umount，然后再拔，能避免绝大多数U盘文件系统损坏的问题。
第二，分区表用GPT别用MBR。现在U盘和移动硬盘容量越来越大，超过2TB的盘MBR根本认不全。虽然挂载单个分区不受影响，但GPT更稳健，尤其在Linux下，parted /dev/sdb mklabel gpt一行搞定，不要再用老掉牙的fdisk了。
第三，某些情况下，U盘插上CentOS 7，系统会把它识别成/dev/sda而不是/dev/sdb，这通常发生在服务器只有一块SCSI/SAS盘，USB控制器枚举顺序靠前时。这时候一定要核对磁盘大小和lsblk输出，别再傻傻认准/dev/sdb。
第四，如果你的CentOS 7服务器上插着多块移动硬盘，建议给每块盘贴一个标签，然后按UUID顺序在fstab里配置固定挂载点，比如/mnt/disk1、/mnt/disk2，这比靠设备名判断靠谱得多，也方便脚本自动备份。
第五，移动硬盘长时间不用时，系统可能会因为USB autosuspend机制自动挂起设备，下次访问时会有几秒钟的延迟。如果频繁遇到这种"卡一下才有反应"的情况，可以试试关闭USB autosuspend：
echo -1 > /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms不过这个操作是临时生效的，想要永久生效得配udev规则，一般用户用不上，知道有这回事就行。
说实话，挂载一个U盘这件事本身不难，但把它在CentOS 7上彻底搞明白、遇到问题不慌，需要一点积累。希望这篇文章能帮你把这块短板补上。如果你在操作过程中遇到文章里没写到的问题，欢迎留言交流，我尽量答复。
