CIFS mounted volume-cannot write big files from Win7 or 10

[philhu]

FreeNAS volume mounted on Win7 or 10

70TB with 35TB free

This all worked a day ago.

Try to copy 3 files to the drive, 4GB, 300k, 1Meg

The small ones go across just fine, the large one copies, then at the end says you will need admin priv to do that. If I say try again, it does the copy again, and asks the same way.

The drive is set to me as the owner of the folder and all data files are 666, the dirs are 777

zpool status shows nothnig wrong:

Code:

[philhu@freenas] /mnt/volume1/data/video/Movie_Underground/Drama# zpool status
  pool: freenas-boot
state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Fri Jul 29 03:45:06 2016
config:

        NAME                                            STATE     READ WRITE CKSUM
        freenas-boot                                    ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            gptid/7cbdc60f-9f88-11e0-902e-0019b92bb372  ONLINE       0     0     0
            ada3p2                                      ONLINE       0     0     0

errors: No known data errors

  pool: volume1
state: ONLINE
  scan: scrub repaired 0 in 31h39m with 0 errors on Mon Jul 18 07:39:07 2016
config:

        NAME                                            STATE     READ WRITE CKSUM
        volume1                                         ONLINE       0     0     0
          raidz3-0                                      ONLINE       0     0     0
            gptid/c998b63d-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cabe3c7b-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cb560878-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cbef8b60-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cc7ea314-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cd0f5146-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cd9eac0e-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/ce2a118e-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cebb4f95-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cf4ba2ec-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
            gptid/cfdd85b3-290d-11e6-b18e-0025902ae8aa  ONLINE       0     0     0
          raidz3-2                                      ONLINE       0     0     0
            gptid/4979d7f2-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4a4c80cc-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4b12e2e9-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4bd76874-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4c972f39-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4d535eb0-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4e7c520d-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/4fa6ccf1-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/50c3d025-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/51e73130-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
            gptid/52a39fee-38c4-11e6-b3f6-0025902ae8aa  ONLINE       0     0     0
        logs
          gptid/e3ff287f-3189-11e6-b68d-0025902ae8aa    ONLINE       0     0     0
        cache
          gptid/d53c311a-3189-11e6-b68d-0025902ae8aa    ONLINE       0     0     0

errors: No known data errors

Any ideas what is going on?

Another piece of the puzzle

I did a windows properties on a directory doing this, it shows some read only files.

I unchecked this, said to do subfolders etc.

Each file comes back 'invalid file handle'

And no vdev is full.....
See this:

Code:

[philhu@freenas] /mnt/volume1/data/video/Movie_Underground/Drama# zpool list -v volume1
NAME                                     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
volume1                                  100T  53.0T  47.0T         -    26%    52%  1.00x  ONLINE  /mnt
  raidz3                                  40T  34.0T  6.05T         -    42%    84%
    gptid/c998b63d-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cabe3c7b-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cb560878-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cbef8b60-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cc7ea314-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cd0f5146-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cd9eac0e-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/ce2a118e-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cebb4f95-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cf4ba2ec-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
    gptid/cfdd85b3-290d-11e6-b18e-0025902ae8aa      -      -      -         -      -      -
  raidz3                                  60T  19.0T  41.0T         -    16%    31%
    gptid/4979d7f2-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4a4c80cc-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4b12e2e9-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4bd76874-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4c972f39-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4d535eb0-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4e7c520d-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/4fa6ccf1-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/50c3d025-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/51e73130-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
    gptid/52a39fee-38c4-11e6-b3f6-0025902ae8aa      -      -      -         -      -      -
log                                         -      -      -         -      -      -
  gptid/e3ff287f-3189-11e6-b68d-0025902ae8aa  14.9G   724K  14.9G         -    58%     0%
cache                                       -      -      -         -      -      -
  gptid/d53c311a-3189-11e6-b68d-0025902ae8aa   224G  74.9G   149G         -     0%    33%

 

[m0nkey_]

You've used the wrong dataset type. Create your dataset as Windows to correctly use Windows style permissions. See my video in my signature for a how-to on Samba.

 

[philhu]

Well. The same dataset is read by linux and freebsd cluents in nfs mode. This is only 2 win clients and it has been working a month

How can I make it so a win client can write to this share? Is there a way to login to a user on the freenas to mount the drive with all permissions ?

And why would small files work and large ones fail?

 

[m0nkey_]

You shouldn't be mixing protocols on shares, as you will run into these issues. It's one share per dataset. As per the documentation:

Note: while the GUI will let you do it, it is a bad idea to share the same volume or dataset using multiple types of access methods. Different types of shares and services use different file locking methods. For example, if the same volume is configured to use both NFS and FTP, NFS will lock a file for editing by an NFS user, but a FTP user can simultaneously edit or delete that file. This will result in lost edits and confused users. Another example: if a volume is configured for both AFP and CIFS, Windows users may be confused by the extra filenames used by Mac files and delete the ones they don’t understand; this will corrupt the files on the AFP share. Pick the one type of share or service that makes the most sense for the types of clients that will access that volume, and configure that volume for that one type of share or service. If you need to support multiple types of shares, divide the volume into datasets and use one dataset per share.

 

[philhu]

So the fact it was wirking all this time was a fluke? And same with large file writing not working? Ok. I will build a xfer smb share. Move files to it. Then use a shell to move them to correct place

 

[SweetAndLow]

Why not just use smb from the Linux clients? That seems like the best solution.

 

[philhu]

Well. I do not think this is the problem. I took down all the nfs clients, built a smb only share, mounted it to the windows box. Same problem

This all worked 2 days ago. And small files write fine. Could I be fragged or running out of handles?

I also tried writing to a iscsi volume and that worked

 

[SweetAndLow]

Output of testparm on freenas? I suspect you have random vfs objects or your clients are messed up.

 

[philhu]

Funny a few other large (80g) files seem to wrute fine.
Testparm here you go.

Code:

Load smb config files from /usr/local/etc/smb4.conf
Processing section "[cifsxfer]"
Processing section "[volume1]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
        dos charset = CP437
        server string = FreeNAS Server
        server role = standalone server
        security = USER
        map to guest = Bad User
        obey pam restrictions = Yes
        guest account = philhu
        logging = file
        max log size = 51200
        server max protocol = SMB2
        max protocol = SMB2
        protocol = SMB2
        time server = Yes
        deadtime = 15
        kernel change notify = No
        max open files = 1414451
        hostname lookups = Yes
        load printers = No
        printcap name = /dev/null
        disable spoolss = Yes
        lm announce = Yes
        dns proxy = No
        pid directory = /var/run/samba
        panic action = /usr/local/libexec/samba/samba-backtrace
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        acl allow execute always = Yes
        create mask = 0666
        directory mask = 0777
        directory mode = 0777
        ea support = Yes
        directory name cache size = 0
        store dos attributes = Yes
        strict locking = No
        dos filemode = Yes


[cifsxfer]
        comment = smb volume
        path = /mnt/volume1/cifsxfer
        read only = No
        guest ok = Yes
        veto files = /.snapshot/.windows/.mac/.zfs/
        vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr recycle
        zfsacl:acesort = dontcare
        nfs4:chown = true
        nfs4:acedup = merge
        nfs4:mode = special
        shadow:snapdirseverywhere = yes
        shadow:format = auto-%Y%m%d.%H%M-2w
        shadow:localtime = yes
        shadow:sort = desc
        shadow:snapdir = .zfs/snapshot
        recycle:subdir_mode = 0700
        recycle:directory_mode = 0777
        recycle:touch = yes
        recycle:versions = yes
        recycle:keeptree = yes
        recycle:repository = .recycle/%U


[volume1]
        comment = TOP Level
        path = /mnt/volume1
        read only = No
        hosts allow = 192.168.1.0/24
        veto files = /.snapshot/.windows/.mac/.zfs/
        vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr recycle
        zfsacl:acesort = dontcare
        nfs4:chown = true
        nfs4:acedup = merge
        nfs4:mode = special
        shadow:snapdirseverywhere = yes
        shadow:format = auto-%Y%m%d.%H%M-2w
        shadow:localtime = yes
        shadow:sort = desc
        shadow:snapdir = .zfs/snapshot
        recycle:subdir_mode = 0700
        recycle:directory_mode = 0777
        recycle:touch = yes
        recycle:versions = yes
        recycle:keeptree = yes
        recycle:repository = .recycle/%U
[philhu@freenas] /mnt/volume1# 

 

[philhu]

ok, so it was none of the above.

For some reason I do not understand, only the ONE FILE was doing that

I transferred 1g-16g files, and they all worked BUT THIS ONE

So I used smbclient to retrieve the file to my centos box, and mv'ed it to the correct directory.

 

[anodos]

ok, so it was none of the above.

For some reason I do not understand, only the ONE FILE was doing that

I transferred 1g-16g files, and they all worked BUT THIS ONE

So I used smbclient to retrieve the file to my centos box, and mv'ed it to the correct directory.

It's possible that the permissions were jacked up on that file. Hard to say without digging in much, much deeper. This is because you have to account for interactions between ACLs, Posix mode bits, samba, and NFS. All of this is kind of demotivating from the standpoint of a 3rd party.

 

[philhu]

must have been source permissions because it was a new write.

Although, I tried moving it locally and tried writing it to 3 places on the NAS, all failed except writing it to an IScsi drive

wierd symptom too, the file did the move, showed uo in the destination directory and asked for permissions after the write. It I say try again, it sends it down again. If I say cancel, it deletes the destination file.

Looks to me like it had trouble, as you said, setting permissions or owner after it finished the transfer.