Yes, NTFS very often shows up as fuseblk; that’s a very common thing.
Thanks for that information.
It certainly means so. As shown above:
Owned by root:root, but all permissions are on, also that of my.
And I still can not match a permission problem with what the message says.
SELinux again? (I know stupid question from one that does not use it).
Since the partition is already mounted with rw and ntfs-3g is installed, I would look beyond the basic mount configuration.
The fuseblk filesystem type is normal for an NTFS partition mounted through ntfs-3g. Also, the user_id=0,group_id=0 options indicate that the filesystem is mounted as root, so permissions are unlikely to be the problem here, especially since you are running the copy command as root.
I would try a couple of tests to narrow this down.
First, check whether the filesystem allows creating a new empty file:
touch /mnt/my/testfile.txt
Then try creating a directory:
mkdir /mnt/my/testdir
If both commands fail with the same error, the problem is likely at the NTFS filesystem or driver level rather than with cp or Midnight Commander.
Next, check the NTFS volume’s read/write status:
ntfs-3g.probe --readwrite /dev/sda7
echo $?
Also check the kernel messages immediately after a failed write:
journalctl -k -b | grep -iE 'ntfs|fuse|I/O error'
I would also try mounting the partition explicitly through ntfs-3g, rather than relying on the generic mount command:
umount /mnt
ntfs-3g /dev/sda7 /mnt
Before doing any filesystem repair, make sure important data is backed up. If the tests still fail, I would check the NTFS volume from Windows using chkdsk /f and perform a full shutdown before trying again.
One important detail: since you can read files from the NTFS partition but cannot create new ones, we need to establish whether NTFS itself is rejecting write operations or whether there is an issue with the NTFS-3G driver in Leap 16. The output of the tests above should help distinguish between those possibilities.
1 Like
cannot create regular file '/mnt/my/blk2.txt': Invalid argument is not a permission denied error, rather it points to something illegal for the file that is being copied.
Something in the name of the file (but that is not the case apparently…) or something in its content (a long list of commands… maybe with some character illegal to Windows…), so trying to create empty files or simple text files should show something interesting.
Wild guess: NTFS being case-insensitive, and a file with a slightly different combination of upper- and lowercase letters already existing?
E.g. there is already a file /mnt/my/BLK2.TXT, and you want to create /mnt/my/blk2.txt which would be the same as the other one?
I recall similar problems on USB sticks when trying to back up my music collection; rsync refused to sync my U2 albums because there already was a directory “u2”, which it did not detect as equivalent, but it couldn’t create another directory “U2”, and I also got a weird error message.
There might be a mount option to convert all letters to lowercase (or something like that). This might help.
But this is all just wild speculation.
Files on an NTFS volume mounted in Linux are case-sensitive.
Technically, at the lower level of Win itself, they are also … but upper layers within Win (at the user level) files are treated as case-insensitive. (has been my experience).
As win10 refugee I set up my lap one year ago and choose Leap 16. Here my output of mount
sdb1 ntfs formatted usb-disk
georg@heka:/run/media/georg/Sicherung> LANG=C
georg@heka:/run/media/georg/Sicherung> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
|-sda1 8:1 0 8M 0 part
|-sda2 8:2 0 463.8G 0 part /var
| /usr/local
| /opt
| /home
| /srv
| /root
| /boot/grub2/i386-pc
| /boot/grub2/x86_64-efi
| /.snapshots
| /
`-sda3 8:3 0 2G 0 part [SWAP]
sdb 8:16 0 931.5G 0 disk
`-sdb1 8:17 0 931.5G 0 part /run/media/georg/Sicherung
sr0 11:0 1 1024M 0 rom
georg@heka:/run/media/georg/Sicherung> mount
/dev/sda2 on / type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=266,subvol=/@/.snapshots/1/snapshot)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=958409,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=1540996k,nr_inodes=819200,mode=755,inode64)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,nosuid,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=3913)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,seclabel,pagesize=2M)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=265,subvol=/@/.snapshots)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@/boot/grub2/x86_64-efi)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@/boot/grub2/i386-pc)
/dev/sda2 on /root type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=262,subvol=/@/root)
/dev/sda2 on /srv type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@/srv)
/dev/sda2 on /home type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=264,subvol=/@/home)
/dev/sda2 on /opt type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=263,subvol=/@/opt)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel,size=3852484k,nr_inodes=1048576,inode64)
/dev/sda2 on /usr/local type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@/usr/local)
/dev/sda2 on /var type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@/var)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=770496k,nr_inodes=192624,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
/dev/sdb1 on /run/media/georg/Sicherung type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
georg@heka:/run/media/georg/Sicherung> touch BLK2.TXT
georg@heka:/run/media/georg/Sicherung> cp BLK2.TXT blk2.txt
georg@heka:/run/media/georg/Sicherung> ls -la .
total 17113301
drwxrwxrwx 1 georg georg 0 Jun 8 2022 $RECYCLE.BIN
drwxrwxrwx 1 georg georg 4096 Oct 30 20:33 .
drwxr-x---+ 3 root root 60 Oct 30 19:40 ..
drwxrwxrwx 1 georg georg 0 Feb 10 2023 .Trash-1000
drwxrwxrwx 1 georg georg 4096 Dec 8 2023 08-12-2023 13-57-03
drwxrwxrwx 1 georg georg 4096 Jun 15 2024 15-06-2024 08-48-49
drwxrwxrwx 1 georg georg 0 Mar 16 2024 16-03-2024 09-52-05
-rwxrwxrwx 1 georg georg 0 Oct 30 20:33 BLK2.TXT
drwxrwxrwx 1 georg georg 0 Dec 8 2023 Backups
-rwxrwxrwx 1 georg georg 17403215872 Sep 25 2023 Debian i386.vdi
drwxrwxrwx 1 georg georg 36864 Oct 25 09:14 Nextcloud-BU
drwxrwxrwx 1 georg georg 0 Mar 16 2024 System Volume Information
-rwxrwxrwx 1 georg georg 120754176 Jun 15 2024 backup.bshdb
-rwxrwxrwx 1 georg georg 2 Jun 15 2024 backup.bshv
-rwxrwxrwx 1 georg georg 0 Oct 30 20:33 blk2.txt
georg@heka:/run/media/georg/Sicherung>
To me all is working as expected.
I would first check how the NTFS partition is being mounted in Leap 16. The problem may not be with cp or Midnight Commander itself.
Could you share the output of these commands?
lsblk -f
findmnt -t ntfs,ntfs3,fuseblk
Also, try creating a small test file directly on the mounted partition:
touch /path/to/mounted/partition/testfile.txt
If that fails, check the kernel messages immediately afterward:
sudo journalctl -k -b | grep -iE 'ntfs|fuse|I/O error'
There are a few things worth checking:
-
Windows Fast Startup or hibernation: If Windows was not fully shut down, its NTFS partition may be left in a hibernated or inconsistent state. Linux may then refuse write access to protect the filesystem. Try disabling Fast Startup in Windows and performing a full shutdown.
-
NTFS driver: Check whether the partition is mounted using the kernel’s
ntfs3driver orntfs-3gthrough FUSE. The mount options and error messages can help identify whether this is a driver-related issue. -
Filesystem errors: If Windows reports filesystem problems, check the partition with
chkdskfrom Windows. Back up important data before attempting repairs.
I would avoid forcing a read-write mount or running filesystem repair commands until we know why the write operation is failing.
Most importantly, could you share the exact error message produced by cp or Midnight Commander? Also, does the partition allow you to create directories or empty files, or are all write operations failing?
That information should help narrow down whether this is a mounting issue, an NTFS filesystem condition, or a compatibility problem with the driver used by Leap 16.
DIAGNOSTICS AS FOLLOWS:
lcl:/mnt/my # lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ntfs Wiederherstellung F0A2DC28A2DBF158
├─sda2 vfat FAT32 44E1-5ACC
├─sda3
├─sda4 ntfs 84A60566A60559D6
├─sda5 vfat FAT32 2E43-6CA2
├─sda6 ntfs ECD2FA14D2F9E32E
└─sda7 ntfs 52C0FEFAC0FEE361 142,9G 71% /mnt
sdb
├─sdb1 btrfs 962716f4-092f-48f1-b1f7-f0ea43484acb 186,5G 58% /home
│ /root
│ /var
│ /boot/grub2/x86_64-efi
│ /opt
│ /usr/local
│ /srv
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
├─sdb2 swap 1 0dc03b14-14d7-49f2-929a-8ab43591c3d5 [SWAP]
├─sdb4
└─sdb5 ext4 1.0 c0cfde57-5937-404f-8aa5-6bc526256b7f
sr0
lcl:/mnt/my # findmnt -t ntfs,ntfs3,fuseblk
TARGET SOURCE FSTYPE OPTIONS
/mnt /dev/sda7 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096
lcl:/mnt/my #
NEXT:
lcl:/mnt/my # touch testfile.txt
touch: cannot touch 'testfile.txt': Invalid argument
NEXT:
lcl:/mnt/my # journalctl -k -b | grep -iE 'ntfs|fuse|I/O error'
Oct 31 18:15:04 lcl.home systemd[1]: Starting Load Kernel Module fuse...
Oct 31 18:15:04 lcl.home kernel: fuse: init (API version 7.41)
FAST STARTUP OR HIBERNATION ARE DEACTIVATED IN WINDOWS 10
NEXT:
lcl:/mnt/my # mkdir TESTDIRECTORY
mkdir: cannot create directory 'TESTDIRECTORY': Invalid argument
NEXT: create new directory in mc produces error message:
invalid argument(22)
FILE SYSTEM ERRORS IN WINDOWS10: not yet investigated.
MORE DIAGNOSTICS:
lcl:~ # umount /mnt
lcl:~ # ntfs-3g /dev/sda7 /mnt
df then shows the partition is mounted.
BUT AGAIN:
lcl:~ # cp blk2.txt /mnt/my
cp: cannot create regular file '/mnt/my/blk2.txt': Invalid argument
So it is impossible to write anything on that partition. What did you use to write to that “in the past”? Can you write to it with a live CD of your choice (or for instance openSUSE-Tumbleweed-Rescue-CD-x86_64-Current.iso)?
My guess is that there is something really wrong with the file system. Can you run a check/repair program on it on Windows (something like we use fsck and friends on Unix/Linux)?
YES, – I do not currently have a live CD of Tumbleweed — but I used a live Fedora ISO on USB stick for booting. And indeed in the live Fedora system I could mount
Windows partition /dev/sda7 and was able to create a new directory there.
After rebooting under opensuse Leap16 the new directory was still there.
This means the Windows partition is writable in principle.
At this point all I can say is “I cannot reproduce”, neither in Leap 16.0 nor in Tumbleweed. Whatever I try (mount ro, mount to unprivileged user…) I cannot get the “invalid argument” error, while I get “permission denied”, “Readonly file system” etc.
So apparently there is something in that ntfs filesystem and/or in the specific config of that Leap 16.0 that I cannot figure out, sorry.
Could you try the following and report the results?
touch /mnt/testfile
touch /mnt/my/testfile
Similar to what OrsoBruno asked you back in post #18 
This will help establish whether the problem is with writing to the NTFS filesystem generally or something specific to the my directory.
And perhaps check for relevant kernel/FUSE messages immediately after a failed write…
sudo journalctl -b -k | tail -50
To the OP, why not start fresh. Remove the ntfs partition then remount it and call the ntfs-3g for mounting the ntfs partition. openSUSE has a good documentation to mount using fuse ntfs-3g. Arch also have a detailed wiki for it.