# ntfs-3g: Failed to access volume '/dev/sdc1': No such file

## jhon987

Hello, this is an issue I've been having for a while now and decided to try and tackle it.

I have an external HDD permanently connected to my PC via a USB3 port, so I added the following in fstab:

```
/dev/sdc1      /media/USB   ntfs-3g      user,auto   0 0
```

however, on first boots the drive almost never loads and this is the error rc.log throws:

```
localmount         | * Mounting local filesystems ...

localmount         |ntfs-3g: Failed to access volume '/dev/sdc1': No such file or directory

localmount         |

localmount         |ntfs-3g 2017.3.23 external FUSE 29 - Third Generation NTFS Driver

localmount         |Configuration type 7, XATTRS are on, POSIX ACLS are on

localmount         |

localmount         |Copyright (C) 2005-2007 Yura Pakhuchiy

localmount         |Copyright (C) 2006-2009 Szabolcs Szakacsits

localmount         |Copyright (C) 2007-2017 Jean-Pierre Andre

localmount         |Copyright (C) 2009 Erik Larsson

localmount         |

localmount         |Usage:    ntfs-3g [-o option[,...]] <device|image_file> <mount_point>

localmount         |

localmount         |Options:  ro (read-only mount), windows_names, uid=, gid=,

localmount         |          umask=, fmask=, dmask=, streams_interface=.

localmount         |          Please see the details in the manual (type: man ntfs-3g).

localmount         |

localmount         |Example: ntfs-3g /dev/sda1 /mnt/windows

localmount         |

localmount         |News, support and information:  http://tuxera.com

localmount         | * Some local filesystem failed to mount

 [ !! ]
```

usually, upon reboot though, it mounts fine.

/media and /dev do not have separate mount points, I have a simple fstab - everything loads in one go  aside from swap (no initramfs): 

```
/dev/sda3      /      ext4      noatime      0 1
```

Also, after first boot, I can manually mount the drive as well, so it's not a corrupted hard drive, I believe.

I assume it's caused due to some synchronization issue, perhaps it takes time till the USB port or HDD be recognized by the kernel or something, but I can't pinpoint what it is thus I can't fix it...

Any suggestions?

BTW, the following dmesg lines may or may not be related:

```
[    1.827601] usb 1-14: new full-speed USB device number 4 using xhci_hcd

[    1.954582] usb 1-14: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping

[    1.954587] usb 1-14: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping

[    1.954596] usb 1-14: New USB device found, idVendor=8087, idProduct=0aaa, bcdDevice= 0.02

[    1.954600] usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[    2.396565] udevd[1970]: starting version 3.2.9

[    2.404484] random: udevd: uninitialized urandom read (16 bytes read)

[    2.451896] scsi 6:0:0:0: Direct-Access     WD       Elements 1078    1056 PQ: 0 ANSI: 6

[    2.452143] sd 6:0:0:0: Attached scsi generic sg2 type 0

[    2.452538] sd 6:0:0:0: [sdc] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)

[    2.452854] sd 6:0:0:0: [sdc] Write Protect is off

[    2.452858] sd 6:0:0:0: [sdc] Mode Sense: 53 00 10 08

[    2.453205] sd 6:0:0:0: [sdc] No Caching mode page found

[    2.453209] sd 6:0:0:0: [sdc] Assuming drive cache: write through

```

----------

## Tony0945

When it fails to mount, what does "fdisk -l" show? Maybe the device isn't always on /dev/sdc. If sdb and sdc occasionally swap you will have this symptom.

Another idea, try mounting in /etc/local.d/99.mount and put "noauto" in /etc/fstab. The delay may give more rime for the drive to be recognized.

```
echo "mount /dev/sdc1" >>/etc/local.d/99.mount
```

----------

## jhon987

 *Tony0945 wrote:*   

> When it fails to mount, what does "fdisk -l" show?

 

I'll try to test that next time I turn on my PC, though, as I wrote, even on first boots - when it fails - if I manually type the command in terminal: mount /dev/sdc1 then it works

 *Tony0945 wrote:*   

> Another idea, try mounting in /etc/local.d/99.mount and put "noauto" in /etc/fstab. The delay may give more rime for the drive to be recognized.
> 
> ```
> echo "mount /dev/sdc1" >>/etc/local.d/99.mount
> ```
> ...

 

I'll give it a go and post my results (probably tomorrow).

Thanks for your help

----------

## Tony0945

Been a while since I did this.  *Quote:*   

> This directory should contain programs or scripts which are to be run
> 
> when the local service is started or stopped.
> 
> If a file in this directory is executable and it has a .start extension,
> ...

 

So that should have been:

```
echo "mount /dev/sdc1" >>/etc/local.d/99mount.start
```

Or a similar name ending in .start

----------

## jhon987

So here are the results for fdisk -l:

```
Disk /dev/sdc: 931.5 GiB, 1000170586112 bytes, 1953458176 sectors

Disk model: Elements 1078   

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0xff8751e4

Device     Boot Start        End    Sectors   Size Id Type

/dev/sdc1        2048 1953458175 1953456128 931.5G  7 HPFS/NTFS/exFAT

```

That's what I expected, as I wrote, manually mounting the drive works.

it could be though, that during the boot process the device still isn't /dev/sdc and only later on assigned that letter, but I cannot issue fdisk -l during the boot process and also, that goes to what I wrote in the first place - that this seem to me a synchronization issue...

I've now added the 99mount.start file, will report once I have findings.

best regards to you Tony

----------

## Tony0945

It is a puzzler. Late detection or changed drive order are all I can think of.

----------

## Ant P.

It's a USB disk, so it probably doesn't exist until after udev's done loading modules. Try putting rc_after="udev-settle" in /etc/conf.d/localmount and see if that fixes things.

----------

## jhon987

 *jhon987 wrote:*   

> I've now added the 99mount.start file, will report once I have findings.

 

So, it didn't work, unfortunately.

in addition to 

```
echo "mount /dev/sdc1" >>/etc/local.d/99mount.start
```

I also made sure to 

```
chmod x+g /etc/local.d/99mount.start
```

because, as the instructions say:

 *Quote:*   

> If a file in this directory is executable

 

However, today I turned on my PC and sdc1 didn't mount automatically.

According to the instructions, 

 *Quote:*   

> it will be run when the local service is started. 

 

So I looked for an error message, but haven't found any, not in rc.log, messages, nor syslog.

```
 [ ok ]

local              | * Starting local ...

 [ !! ]

rc default logging stopped at Fri Dec 13 12:32:22 2019
```

 *Ant P. wrote:*   

> It's a USB disk, so it probably doesn't exist until after udev's done loading modules

 

please note that the local service is the last one to run on the init sequence, so if I understand it correctly, the 99muont.start script should've ran at that point and work, but sdc1 didn't mount.

However, I did find something that I didn't noticed before (dmesg):

```

[    2.453479] scsi 6:0:0:0: Direct-Access     WD       Elements 1078    1056 PQ: 0 ANSI: 6

[    2.453714] sd 6:0:0:0: Attached scsi generic sg2 type 0

[    2.453825] sd 6:0:0:0: [sdc] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)

[    2.454110] sd 6:0:0:0: [sdc] Write Protect is off

[    2.454113] sd 6:0:0:0: [sdc] Mode Sense: 53 00 10 08

[    2.454367] sd 6:0:0:0: [sdc] No Caching mode page found

[    2.454369] sd 6:0:0:0: [sdc] Assuming drive cache: write through

[    2.884497] ip (2410) used greatest stack depth: 12336 bytes left

[    2.936826] EXT4-fs (sda3): re-mounted. Opts: (null)

[    2.990898] Adding 204796k swap on /dev/sda2.  Priority:-2 extents:1 across:204796k SS

[    3.459446] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)

[    6.823150] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  390.132  Fri Nov  1 04:06:17 PDT 2019

[    7.833232]  sdc: sdc1

[    7.834864] sd 6:0:0:0: [sdc] Attached SCSI disk

```

Note the time of the last 2 lines (these lines aren't there when I reboot, if I'm not mistaken)...

Edit: Indeed, upon reboot, these lines come way earlier:

```
[    2.454609]  sdc: sdc1

[    2.455340] sd 6:0:0:0: [sdc] Attached SCSI disk
```

anyways, I'll try your solution Ant P. - putting rc_after="udev-settle" in /etc/conf.d/localmount 

Will report when I have findings

----------

## jhon987

I just tested whether Ant P. solution - putting rc_after="udev-settle" in /etc/conf.d/localmount  - works, unfortunately, that didn't.

I guess I'll just have to live with it. it's not like it's critical or anything, but I'd just wanted to know what's causing it and perhaps fix it, for comfort-ability sake...

----------

## Tony0945

Just booted into my dual boot machine to see how I mount  ntfs

```
/dev/sda1               /cdrive         ntfs-3g         users,noauto,uid=1000,gid=10    0 0

/dev/sda5               /mnt/edrive     ntfs-3g         users,noauto,uid=1000,gid=10    0 0

/dev/sdc1               /mnt/video   ntfs-3g         users,auto,uid=1000,gid=10   0 0

UUID="647A-695C"        /media/kingston ntfs-3g         users,noauto,uid=1000,gid=0     0 0

```

  /dev/sdc and /dev/sda are SATA hard drives. the one mounted by UUID is a usbstick.

So your extrnal drive CAN be mounted by UUID.  Also, maybe the uid/gid entries make a difference.

Group 10 is wheel. User 1000 is tony as in /home/tony.

Also, it looks like you can mount an ntfs drive by label or UUID and maybe partition UUID

```
tony # blkid |grep ntfs

/dev/sda1: LABEL="BLACK_XP" UUID="A2845D01845CD8FD" TYPE="ntfs" PARTUUID="0550bf48-01"

/dev/sda5: LABEL="DATA_DRIVE" UUID="7C9853369852EE60" TYPE="ntfs" PARTUUID="0550bf48-05"

/dev/sdc1: LABEL="BIGVIDEO" UUID="B0F4439FF4436726" TYPE="ntfs" PARTUUID="5ed8d3cd-01"

```

----------

## NeddySeagoon

jhon987,

Is your USB stack built as loadable modules or built into the kernel?

Loadable modules load after root is mounted so the USB startup process cant begin until then,

By the time USB has initialised and the drive spun up, local mount will have finished.

ntfs-3g is a FUSE module.

Try with The USB stack and the FUSE kernel modules all built into the kernel binary.

That gives the most time for USB to be ready in time for local mount.

----------

## Hu

 *jhon987 wrote:*   

> I have an external HDD permanently connected to my PC via a USB3 port, so I added the following in fstab:

 If it is permanent, why are you connecting it over USB3 instead of a connection meant for permanent use, like SATA?

I tend to agree with the other posts that this is an ordering issue.  Perhaps you would be better served removing the fstab entry and relying on udev to mount the device when it appears.

----------

## Ant P.

 *Hu wrote:*   

>  *jhon987 wrote:*   I have an external HDD permanently connected to my PC via a USB3 port, so I added the following in fstab: If it is permanent, why are you connecting it over USB3 instead of a connection meant for permanent use, like SATA?

 

Lack of internal cables? USB3 is more than enough for spinning rust anyway.

I'm out of ideas. At this point I'd suggest using automount, but that's a lot of effort for a single hard disk.

----------

## jhon987

Wow, so many responses!

 *NeddySeagoon wrote:*   

> Try with The USB stack and the FUSE kernel modules all built into the kernel binary.

 

I'm already one step ahead in this case:

```
CONFIG_USB_SUPPORT=y

CONFIG_USB_COMMON=y

CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB=y
```

```
CONFIG_USB_XHCI_HCD=y

# CONFIG_USB_XHCI_DBGCAP is not set

CONFIG_USB_XHCI_PCI=y

CONFIG_USB_XHCI_PLATFORM=y
```

```
CONFIG_FUSE_FS=y
```

 *Hu wrote:*   

> If it is permanent, why are you connecting it over USB3 

 

it's an external (portable) hard disk I bought a few years ago so I could carry it with me if necessary. but in late couple of years and nowadays I never unplug it from my PC (https://www.amazon.com/Elements-Portable-External-Hard-Drive/dp/B06VVS7S94?SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-ffab-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B06W55K9N6&th=1).

 *Hu wrote:*   

> Perhaps you would be better served removing the fstab entry and relying on udev to mount the device when it appears.

 

can you please explain how do I do that or link me to guide?

 *Tony0945 wrote:*   

> So your extrnal drive CAN be mounted by UUID

 

This sounds to me something worth trying. On the other hand, I'm not sure how uid/gid entries could make a difference, but I'll give it a try

 *Ant P. wrote:*   

>  I'm out of ideas. At this point I'd suggest using automount, but that's a lot of effort for a single hard disk.

 

Thanks for your help. I might look into automount later.

----------

## krinn

There's nothing you could really do, your hdd sometimes takes really a lot of time to appears, even after your usb have appears

Tony0945 solution is trying to do that, he is betting: the drive won't be there, so we will try mounting from local start to giving it more time to appears, a bet that is logic, but it doesn't warrant it would still be enough waiting time

The only thing you may do is :

disable mounting it (with noauto), and from local start, loop x times with a delay waiting for sdc1 to comes up

or like Hu suggest, not mounting it at all, and delegating that to udev (when the drive will appears udev should try mount it, however, i think it will do that using ntfs, not ntfs-3g), just like udev would do with an usb key.

if you want keep it the way you handle it now, add nofail as option to prevent the error

----------

## NeddySeagoon

jhon987,

Please test with rootdelay=10 appended to your kernel command line.

Its a horrible hack if it works.

Do you have USB_STORAGE and UAS built into the kernel too?

----------

## jhon987

 *NeddySeagoon wrote:*   

> 
> 
> Please test with rootdelay=10 appended to your kernel command line.
> 
> 

 

Will try that after I finish testing the UUID option Tony suggested and in case it fails.

BTW,  rootdelay will delay the entire filesystem and thus the booting process wouldn't it? is there a way to delay only the mount of sdc1?

 *NeddySeagoon wrote:*   

> 
> 
> Do you have USB_STORAGE and UAS built into the kernel too?

 

partly:

```
CONFIG_USB_STORAGE=y

# CONFIG_USB_UAS is not set
```

According to the kernel description:

```
CONFIG_USB_UAS:                                                                   │  

  │                                                                                   │  

  │ The USB Attached SCSI protocol is supported by some USB                           │  

  │ storage devices.
```

I don't see anything regarding scsi in the WD Elements page (https://shop.westerndigital.com/products/portable-drives/wd-elements-portable-usb-3-0-hdd#WDBUZG0010BBK-WESN) so I don't know if it even supports the protocol, do you think it could help? (I've enabled it, built-in the kernel)

 *krinn wrote:*   

> 
> 
> and from local start, loop x times with a delay waiting for sdc1 to comes up 

 

do you mean I shuold use the /etc/local.d/ folder and write a script that will loop the mount until it succeed?

 *krinn wrote:*   

> if you want keep it the way you handle it now, add nofail as option to prevent the error

 

will do.

----------

## NeddySeagoon

jhon987,

Yes, rootdelay delays the whole boot process.

Its easy to get at the grub menu, which I why I said its a hack. Its not a permanent solution.

You can put a sleep command in the script in /etc/local.d/ folder that does the late mount of sdc1.

That only affects sdc1.

UAS is harmless. It will only be used if the USB storage device understands it.

When its used you get the full SCSI command set over USB. Native Command Queuing, overlapping commands, DMA etc.

Bulk mode is like the old IDE PIO, where all the data is transferred by the CPU.

----------

## jhon987

Ok guys, I'm happy to report an apparent progress.

Today, as I turned on my PC, when it reached the:

```
localmount         | * Mounting local filesystems ...
```

openrc, seem to have have halt for a couple seconds and then continued on without reporting a fail. 

This time, upon cold boot, my sdc partition did mount!

What I did was changing the fstab entry to a UUID (plus the uid/gid, as per Tony suggested).

I also added nofail (as per krinn), so I guess, even if it did fail to mount, I wouldn't get an error message (am I right?).

Lastly, I enabled CONFIG_USB_UAS built-in to the kernel, so it might have helped.

note dmesg timings were a bit different this time:

```

[    2.450763] scsi 6:0:0:0: Direct-Access     WD       Elements 1078    1056 PQ: 0 ANSI: 6

[    2.451055] sd 6:0:0:0: Attached scsi generic sg2 type 0

[    2.451261] sd 6:0:0:0: [sdc] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)

[    2.451561] sd 6:0:0:0: [sdc] Write Protect is off

[    2.451565] sd 6:0:0:0: [sdc] Mode Sense: 53 00 10 08

[    2.451869] sd 6:0:0:0: [sdc] No Caching mode page found

[    2.451990] sd 6:0:0:0: [sdc] Assuming drive cache: write through

[    7.901260]  sdc: sdc1

[    8.097513] sd 6:0:0:0: [sdc] Attached SCSI disk

```

Anyways, this might have been a random coincidence (remember what I wrote in the beginning "on first boots the drive almost never loads..."), I shall have to test a few more times to be sure.

If it isn't a coincidence, then I think the cause for change might have been either the use of UUID or the CONFIG_USB_UAS kernel setting.

Thanks to everyone who contributed their thoughts.

If you're celebrating a holiday today - happy holiday to whom might read this

----------

## NeddySeagoon

jhon987,

Its a spin up time race condition. If the drive is ready, it works. If not, it fails.

Using UUID takes a little longer as the kernel has to read all the filesystems to determine the UUID.

I wouldn't be at all surprised to learn that it works when the drive is warm but not when its cold as that will impact the spin up time.

UAS won't help the drive being detected, only the data transfer rate and CPU load when the drive is in use.

----------

## jhon987

Thank U NeedySeagoon, as usual, you are affluent with knowledge.

After a few cold boots, it seems using UUID is indeed the solution to the issue. That is, not to say that at some random point in the future the drive might not mount (it hasn't failed me yet), but even if it will, still it's better than failing to mount at almost every cold boot.

Indeed, the boot process as a whole does take longer, as you said. 

I still am left puzzled regarding the culprit of the issue - that is, why when I tried to use Tony's solution (/etc/local.d/99mount.start) which ran at the very end of the init process, it didn't work - is it or is it not a timing issue? unfortunately, rc.log doesn't include timings so I can't compare it to the time dmesg mentions sdc, nor does rc.log contained a message whether the mount.start file executed and worked..

BTW, I removed the uid,gid from fstab. as I was sure they has no impact in this case - indeed, they didn't.

Best regards to all

----------

## NeddySeagoon

jhon987,

The uid,gid in fstab have no impact on the success or otherwise of the mount.

As ntfs does not support *NIX permissions, the entries will affect who can access the mount.

----------

## Tony0945

 *NeddySeagoon wrote:*   

> The uid,gid in fstab have no impact on the success or otherwise of the mount.
> 
> As ntfs does not support *NIX permissions, the entries will affect who can access the mount.

 

I really don't remember where I picked that up. It's probably to prevent unauthorized use. Since no one but me EVER uses that PC, I suppose it's not needed. Doesn't hurt though. In the general case, this being a dual-boot machine, I think it would prevent a non-wheel Linux user without a Windows login to access the Windows drives. And allowing general access to USB sticks is undoubtedly a security issue!

----------

