# [resolved]Copying files to ntfs partition cannot create file

## BillWho

This is driving me up the proverbial wall. I've copied files to ntfs partitions numerous time before, but all of a sudden I get:

```
root@gentoo-gateway bill # cp Scanned_doc.jpg /media/win7

‘Scanned_doc.jpg’ -> ‘/media/win7/Scanned_doc.jpg’

cp: cannot create regular file ‘/media/win7/Scanned_doc.jpg’: No such file or directory

```

The partition is mounted rw:

```
/dev/sda2    on  /media/win7               type  fuseblk      (rw,nosuid,nodev,allow_other,blksize=4096)
```

I had found that NTFS write support wasn't set so I figured I discovered the problem, but it still refuses to copy after it was enabled.

                                                               <M> MSDOS fs support                                                                                                                 │ │  

  │ │                                                               <M> VFAT (Windows-95) fs support                                                                                                     │ │  

  │ │                                                               (437) Default codepage for FAT                                                                                                       │ │  

  │ │                                                               (iso8859-1) Default iocharset for FAT                                                                                                │ │  

  │ │                                                               <M> NTFS file system support                                                                                                         │ │  

  │ │                                                               [ ]   NTFS debugging support                                                                                                         │ │  

  │ │                                                               [*]   NTFS write support                                                                                                             │ │  

Fuse and ntfs modules are loaded:

```
root@gentoo-gateway linux # lsmod|grep "ntfs\|fuse"

ntfs                  155035  0 

fuse                   56733  3 

```

The use flags for ntfs3g and fuse are:

```
[ebuild   R    ] sys-fs/fuse-2.9.1-r1  USE="static-libs" 0 kB

[ebuild   R    ] sys-fs/ntfs3g-2012.1.15-r2  USE="acl crypt external-fuse extras ntfsprogs static-libs -debug -suid -xattr" 0 kB

```

I have another gentoo installation running 3.3.8 kernel and it's able to move/copy to the ntfs partition so the only difference I can determine is that this computer is at 3.6.0-rc1   :Confused: 

Is there anything else that I might be missing here or is there a ntfs bug with 3.6.0-rc1    :Question: 

----------

## Fitzcarraldo

I'm not using 3.6.0-rc1 kernel so have no idea, but just wondered why your fstab is the way it is? Mine is a lot simpler:

```
$ uname -r

3.3.5-gentoo
```

```
$ cat /usr/src/linux/.config | grep -i ntfs

CONFIG_NTFS_FS=m

# CONFIG_NTFS_DEBUG is not set

CONFIG_NTFS_RW=y
```

```
$ cat /usr/src/linux/.config | grep -i msdos

CONFIG_MSDOS_PARTITION=y

CONFIG_MSDOS_FS=y
```

```
$ cat /usr/src/linux/.config | grep -i fat

# DOS/FAT/NT Filesystems

CONFIG_FAT_FS=y

CONFIG_VFAT_FS=y

CONFIG_FAT_DEFAULT_CODEPAGE=437

CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
```

```
$ lsmod|grep "ntfs\|fuse" 

fuse                   55618  2
```

```
$ grep media /etc/fstab 

/dev/sda2               /media/Windows7         ntfs-3g defaults        0 0
```

```
$ eix -I sys-fs/fuse

[I] sys-fs/fuse

     Available versions:  2.8.6 (~)2.8.7 (~)2.9.0 (~)2.9.1 (~)2.9.1-r1 {{kernel_FreeBSD kernel_linux static-libs}}

     Installed versions:  2.9.1-r1(18:53:14 11/08/12)(kernel_linux -kernel_FreeBSD -static-libs)

     Homepage:            http://fuse.sourceforge.net

     Description:         An interface for filesystems implemented in userspace.

[I] sys-fs/fuseiso

     Available versions:  20070708

     Installed versions:  20070708(18:52:48 11/04/10)

     Homepage:            http://fuseiso.sourceforge.net/

     Description:         Fuse module to mount ISO9660

Found 2 matches.
```

```
$ eix -I sys-fs/ntfs3g

[I] sys-fs/ntfs3g

     Available versions:  2012.1.15-r1 (~)2012.1.15-r2 {{acl crypt debug +external-fuse extras +ntfsprogs static-libs suid +udev xattr}}

     Installed versions:  2012.1.15-r2(18:58:59 11/08/12)(acl crypt external-fuse ntfsprogs suid -debug -extras -static-libs -xattr)

     Homepage:            http://www.tuxera.com/community/ntfs-3g-download/

     Description:         Open source read-write NTFS driver that runs under FUSE
```

```
$ cp Kim_Choo_Kitchen1.jpg /media/Windows7/

$ ls /media/Windows7/Kim_Choo_Kitchen1.jpg

/media/Windows7/Kim_Choo_Kitchen1.jpg

$
```

----------

## eccerr0r

Yes, need to make sure you're using ntfs3g.  I don't even think the in-kernel ntfs is used when using ntfs3g.

I do have to say that I have not been impressed by FUSE filesystems.  They tend to be slow, but alas, it seems to be the only way to write to newer NTFS partitions (the in-kernel NTFS write support seems to work only with really old NTFS partitions, probably the original NTFS that came with NT4, it seems...)

----------

## BillWho

eccerr0r & Fitzcarraldo,

Thanks for the replies.

This gets stranger yet in that support for NTFS is not enabled on the system that I can copy files to:

```
laptop bill # cp dead.letter /media/win7

`dead.letter' -> `/media/win7/dead.letter'

```

│                                           <*> MSDOS fs support                                                                                              │ │  

  │ │                                           <*> VFAT (Windows-95) fs support                                                                                  │ │  

  │ │                                           (437) Default codepage for FAT                                                                                    │ │  

  │ │                                           (iso8859-1) Default iocharset for FAT                                                                             │ │  

  │ │                                           < > NTFS file system support                                                                                      │ │  

  │ 

I'm going to disable it on the 3.6.0-rc1 setup and see what the results are    :Rolling Eyes: 

----------

## NeddySeagoon

BillWho,

Kernel NTFS write support was very dangerous.  Its been fixed by only allowing it to change the content of exixting files, provided the file size on disk does not change.

You need FUSE support in your kernel, do not use the fuse package, and ntfs-3g.  The filesystem type will be ntfs3g, not ntfs but you get full write support.

----------

## BillWho

 *NeddySeagoon wrote:*   

> BillWho,
> 
> Kernel NTFS write support was very dangerous.  Its been fixed by only allowing it to change the content of exixting files, provided the file size on disk does not change.
> 
> You need FUSE support in your kernel, do not use the fuse package, and ntfs-3g.  The filesystem type will be ntfs3g, not ntfs but you get full write support.

 

Thanks for the reply NeddySeagoon,

I disabled the ntfs support in the kernel and that didn't make a difference. as you alluded to. That explains why the laptop can copy files to ntfs. My fstab is :

```
/dev/sda2   /media/win7         ntfs-3g      defaults               0 0
```

and

```
root@gentoo-gateway linux # grep FUSE .config

CONFIG_FUSE_FS=m

```

I'm really starting to suspect the kernel here. The second gentoo installation on this machine is at 3.3.8 and it copies files to the ntfs partition. What I'm going to try is emerging 3.5_rc7 or 3.3.8 here and see what happens.

@Fitzcarraldo,

I compared your settings against mine and there's really no difference, that I could see, that would prevent the copying the file. If I recall correctly, it worked with 3.5_rc7   :Confused: 

----------

## BillWho

Well, my suspicions were right. reverting to 3.5.0-rc7 resolved the problem.

```
bill@gentoo-gateway ~ $ cp Scanned_doc.jpg /media/win7/

‘Scanned_doc.jpg’ -> ‘/media/win7/Scanned_doc.jpg’

bill@gentoo-gateway ~ $ uname -r

3.5.0-rc7

bill@gentoo-gateway ~ $ 

```

I left ntfs support disabled in the kernel and it's back to normal.

```
root@gentoo-gateway linux # cat /usr/src/linux/.config | grep -i ntfs 

# CONFIG_NTFS_FS is not set

```

I'm going to mark this thread as solved, but should this be reported as a bug   :Question:   I've never reported a kernel bug before   :Confused: 

----------

## keenblade

 *BillWho wrote:*   

> ...
> 
> I'm really starting to suspect the kernel here. The second gentoo installation on this machine is at 3.3.8 and it copies files to the ntfs partition. What I'm going to try is emerging 3.5_rc7 or 3.3.8 here and see what happens.
> 
> 

 

You are right. I tested the kernel-3.6.0-rc2, and the problem is still there. But my regular kernel-3.2.9 works fine.

Fedora fixed this bug. And the upstream fix here.

----------

## BillWho

keenblade,

Thanks for the info on the bug   :Very Happy: 

I copied the patch and applied it to 3.6-rc2 since there weren't any changes from 3.6-rc1, but unfortunately it sent the kernel into a tizzy   :Rolling Eyes: 

I guess I'll just wait until the patches make it into the portage tree so I don't end up destroying my filesystem   :Very Happy: 

```
[   73.388972] kernel BUG at fs/fuse/dir.c:387!

[   73.389075] invalid opcode: 0000 [#1] SMP 

[   73.389187] Modules linked in: it87 hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm fbcon tileblit font bitblit powernow_k8 radeon softcursor ttm drm_kms_helper drm agpgart fb fbdev i2c_algo_bit cfbcopyarea cfbimgblt firewire_ohci firewire_core k10temp mperf processor crc_itu_t i2c_piix4 cfbfillrect snd_timer ohci_hcd snd_page_alloc sky2 pata_atiixp

[   73.390236] CPU 1 

[   73.390291] Pid: 2515, comm: cp Not tainted 3.6.0-rc2 #3 Gateway DX4200-09/RS780

[   73.390473] RIP: 0010:[<ffffffff81216e64>]  [<ffffffff81216e64>] fuse_create_open+0x50/0x368

[   73.390688] RSP: 0018:ffff88010ec83b28  EFLAGS: 00010287

[   73.390815] RAX: 0000000000000000 RBX: ffff880117a58000 RCX: 00000000000080c1

[   73.390983] RDX: ffff88010fb80300 RSI: ffff8801152326c0 RDI: ffff880117a58000

[   73.391144] RBP: ffff88010ec83c48 R08: 00000000000001a4 R09: ffff88010ec83e04

[   73.391314] R10: ffffffff812180da R11: ffff880118c43800 R12: ffff8801152326c0

[   73.391474] R13: 0000000000000000 R14: ffff880118c43800 R15: 00000000000001a4

[   73.391653] FS:  00007f89c4c70700(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000

[   73.391844] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[   73.391980] CR2: 00000000004072fc CR3: 000000010ec55000 CR4: 00000000000007e0

[   73.392139] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[   73.392300] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[   73.392477] Process cp (pid: 2515, threadinfo ffff88010ec82000, task ffff88011b658000)

[   73.392662] Stack:

[   73.392710]  ffff88010ec83b48 ffffffff810fedfb 0000000000000000 ffff88010ec83e04

[   73.392903]  ffff8801000080c1 ffff88010fb80300 ffff880118c401a4 ffff8801152326c0

[   73.393096]  ffff880118c43800 00000000fffffffe ffff88010ec83c48 ffffffff812181e7

[   73.393288] Call Trace:

[   73.393353]  [<ffffffff810fedfb>] ? d_rehash+0x1d/0x26

[   73.393484]  [<ffffffff812181e7>] ? fuse_lookup+0xfb/0x153

[   73.393618]  [<ffffffff812182c7>] fuse_atomic_open+0x88/0xd7

[   73.393753]  [<ffffffff810f9c30>] do_last+0x3ea/0xa4a

[   73.393876]  [<ffffffff810f7c75>] ? inode_permission+0x3c/0x3e

[   73.394021]  [<ffffffff810fa35b>] path_openat+0xcb/0x39b

[   73.394149]  [<ffffffff810d4b47>] ? handle_mm_fault+0xeb/0x100

[   73.394286]  [<ffffffff810fa8e6>] do_filp_open+0x38/0x84

[   73.394424]  [<ffffffff8110433e>] ? alloc_fd+0x6f/0xfe

[   73.394550]  [<ffffffff810ed721>] do_sys_open+0x70/0x102

[   73.394675]  [<ffffffff810ed7cf>] sys_open+0x1c/0x1e

[   73.394802]  [<ffffffff8152a4a2>] system_call_fastpath+0x16/0x1b

[   73.394939] Code: 89 8d 00 ff ff ff 4c 89 8d f8 fe ff ff 66 44 89 85 10 ff ff ff 4c 8b b0 80 03 00 00 44 89 c0 25 00 f0 00 00 3d 00 80 00 00 74 02 <0f> 0b e8 b2 60 00 00 48 85 c0 48 89 85 20 ff ff ff c7 85 2c ff 

[   73.395829] RIP  [<ffffffff81216e64>] fuse_create_open+0x50/0x368

[   73.395977]  RSP <ffff88010ec83b28>

[   73.447585] ---[ end trace 55e7d5529fe4ec85 ]---
```

----------

