why ntfs is not mounted at boot?

yaximik · 01-06-2013, 04:10 PM

It should be an easy question, but I am at loss. I have a USB ntfs drive, which I can mount with no problem (I have ntfs-3g installed on RHEL58 box)

Code:

mount /dev/sdb1 /media/FantomHD

and the drive shows up on desktop. It is then mounted normally after logout and re-login, or log-in as different user (such as root). But it is not mounted at reboot and every time has to be mounted manually as above.
Here is my /etc/fstab, it should work just fine, should it?

Code:

[root@G5NNJN1 yaximik]# more /etc/fstab
LABEL=/boot                                     /boot                   ext3    defaults                1 2
tmpfs                                           /dev/shm                tmpfs   defaults                0 0
devpts                                          /dev/pts                devpts  gid=5,mode=620          0 0
sysfs                                           /sys                    ysfs    defaults                0 0
proc                                            /proc                   proc    defaults                0 0
/dev/VolGroup00/LogVol01                        swap                    swap    defaults                0 0
/dev/VolGroup00/LogVol02                        /usr                    ext3    defaults                1 2
/dev/VolGroup00/LogVol03                        /tmp                    ext3    defaults                1 2
/dev/VolGroup00/LogVol04                        /var                    ext3    defaults                1 2
/dev/VolGroup00/LogVol00                        /                       ext3    defaults,user_xattr     1 1
/dev/VolGroup00/LogVol05                        /home                   ext3    defaults,user_xattr     1 2
UUID=803CC3A53CC39516                           /media/FantomHD         ntfs-3g defaults                1 3
UUID=37bff8a4-583e-11e2-b603-842b2b025e3a       /media/FantomHD2        ext3    defaults                1 3
[root@G5NNJN1 yaximik]#

What may be the problem?

smallpond · 01-06-2013, 04:39 PM

This appears to be a common problem. Looks like fstab gets scanned before the USB is done enumerating devices at boot time, so sometimes USB drives will fail to mount. There's probably a cleaner solution, but I would suggest adding noauto in fstab and add a script that runs mount -a at the end of boot. If you're handy with udev, you could have it mount when the drive is detected, but that might be overkill.

jschiwal · 01-06-2013, 05:31 PM

A better mount option would be "nofail". It will still try to mount the filesystem, but booting will continue if it fails or the device is present.

You might try the boot_delay=n kernel boot parameter

Code:

boot_delay= Milliseconds to delay each printk during boot.

Values larger than 10 seconds (10000) are changed to

no delay (0).

Format: integer

There is also usb-storage.delay_use=n. Try 5 for n. That was the initial value before Linus reduced it to 1. note: it may already be 5. Try "cat /sys/moduke/usb_storage/parameters/delay_use" to check what it is to start with. My kernel defaults to 1 sec.

Code:

boot_delay= Milliseconds to delay each printk during boot.

Values larger than 10 seconds (10000) are changed to

no delay (0).

Format: integer

Some distro's use systemd which defers all mounting of *.targets. If you aren't paying Red Hat for support, as you should (frequent booting and an NTFS usb drive implies home use to me) maybe you should be using
a different distribution such as Fedora or CentOS to stay legal. If you are, maybe ask them for further advice. Another distro that uses systemd now, might work better with the device. (or might introduce more head aches)

If you aren't sharing the NTFS filesystem with a Windows system, then use a native Linux filesystem.

DeadlyWolf · 01-07-2013, 01:33 AM

I would try changing this line in your fstab

Code:

UUID=803CC3A53CC39516                           /media/FantomHD         ntfs-3g defaults                1 3

to

Code:

/dev/sdb1 /media/FantomHD ntfs-3g defaults 0 0

yaximik · 01-07-2013, 07:49 AM

Quote:

a different distribution such as Fedora or CentOS to stay legal. If you are, maybe ask them for further advice. Another distro that uses systemd now, might work better with the device. (or might introduce more head aches)

If you aren't sharing the NTFS filesystem with a Windows system, then use a native Linux filesystem.

Thanks everyone for useful and informative inputs. I do have RH paid support, but I have heard that RH frowns at ntfs-3g use. I still try to open a ticket to see what they say. Normally I do not reboot often, it is this particular issue drives me nuts. It does not seem a USB problem as another USB drive with sxt3 mounts just fine from /etc/fstab. Something about ntfs-3g. I was thinking to change to ext3, but this drive already has ~1TB of data, unless I am ignorant, I will have to transfer the data to another drive before changing the file system.

yaximik · 01-07-2013, 08:06 AM

Quote:

Originally Posted by DeadlyWolf

I would try changing this line in your fstab

Code:

UUID=803CC3A53CC39516                           /media/FantomHD         ntfs-3g defaults                1 3

to

Code:

/dev/sdb1 /media/FantomHD ntfs-3g defaults 0 0

I just followed the advice from a textbook to use UUID instead of device to safeguard against possible change of device names by the system upon reboot, which may halt booting. But I guess jschiwal's suggestion to add 'nofail' option may help in this situation.

Again I may be ignorant here, but 'tune2fs -l ' reports bad superblock and failure to find a valid filesystem for this particular device. Is this because of the ntfs file system or this is the problem? A bad superblock earlier prevented USB drive with ext2 to mount and halted booting; once it was fixed by fsck, converted to ext3 and assigned new UUID by tune2fs it behaves. Can I do the same with ntfs drive or I have to convert it to ext3 first?

goumba · 01-07-2013, 08:40 AM

Quote:

Originally Posted by yaximik

Again I may be ignorant here, but 'tune2fs -l ' reports bad superblock and failure to find a valid filesystem for this particular device. Is this because of the ntfs file system or this is the problem?

tuen2fs will be looking for an ext filesystem on that device, and it does not check for errors. There is no extfs, but ntfs, and that's why you get that error for the device. It has nothing to do with the problem (not to say there is not a problem with the filesystem, just chkdsk under Windows is what you want to check for errors on this drive).

yaximik · 01-08-2013, 07:52 AM

OK, that makes sense, thanks. BTW, I tried replacing UUID with device as recommended, but I also added 'nofail' option to both USB drives' lines. The box did not like that. It did not prevent booting, but both USB drives (ext3 and ntfs) did not mount and the system reported bad corresponding lines in fstab. When I removed 'nofail', both drives mounted nicely after reboot.

jschiwal · 01-09-2013, 06:01 PM

Some mount options like nofail and _netdev are flags that the bootup mounting scripts understand. Sounds like your version of mount doesn't recognize the nofail option. As always, rely on your own man pages as they coorespond to your versions of the programs.

If the external drive is under 1/2 full, you might try using gparted to resize the filesystem (or use MS partition plugin in Vista and up) to resize it down. Then create a new ext3 or ext4 filesystem in the freed up space. You could use tar to create a compressed archive if your new space is around 700MB. Then delete the NTFS partition and resize the new one to fill the drive.

Of course, moving the files to a new drive would be the safest option.
The ntfs repair tool that comes with the ntfs-3g only fixes simple errors. Then it marks the drive as needing checking.
It's expected that you will then use MS's chkdisk program. If you don't use Windows, using NTFS is dangerous in the long run.