SOLVED CIFS/SMB Files cannot be saved on windows after edited on mac

[funnyprinter]

Files cannot be edited through cifs/smb on windows after they have been edited on a mac. Somehow it seems that the file permissions get destroyed through editing/saving on mac.

Problem on Windows
It results in the error on saving:

"The file \\freenas\temp\test.txt can not be created. Please ensure, path and filename is correct".

Exact German error text: "Die Datei \\freenas\temp\test.txt kann nicht erstellt werden. Stellen Sie sicher, dass Pfad- und Dateiname richtig sind".

This results in an prompt for selecting a new path and filename. Reusing the same path ends in the same error. Reusing a different allows to save the file. Deleting files is not affected though.

Problem on Mac
None, mac is able to edit the files at any time

What I do:

1. Create file on Windows with User A> Works
2. Edit and save file on Windows with UserA > Works
3. Edit and save file on Windows with UserB > Works
4. Edit and save file on Mac with UserA > works <<<< Problem starts at this point
5. Edit and save file on Mac with UserB > works
6. Edit and save file on Windows with UserA or UserB does not work an more <<< Problem

I'm using SMB from Mac and Windows! AFP is disabled for avoiding problems!

Logs
The logs while saving and overwriting are the same (log level medium)

Code:

[2016/08/29 17:22:20.102644,  2] ../source3/param/loadparm.c:2701(lp_do_section)
  Processing section "[temp]"
[2016/08/29 17:22:20.129989,  2] ../source3/smbd/open.c:1005(open_file)
  Domain\UserA opened file test-1.txt read=No write=No (numopen=1)
[2016/08/29 17:22:20.132180,  2] ../source3/smbd/close.c:790(close_normal_file)
  Domain\UserA closed file test-1.txt (numopen=0) NT_STATUS_OK

Unix Rights
File settings from shell (not changed through chown,chmod)

Code:

-rw-rw-r--  1 UserA allusers    8 Aug 29 11:52 test-by-mac.txt
-rwxrwxr-x+ 1 UserB  allusers     0 Aug 30 10:33 test-by-windows.txt*

Active Directory and Domain
cut /usr/local/etc/smb4.conf

Code:

[global]

    server max protocol = SMB3_11
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 588197
    logging = file
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = yes
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    server string = FreeNAS File Server
    ea support = yes
    store dos attributes = yes
    lm announce = yes
    acl allow execute always = true
    dos filemode = yes
    multicast dns register = yes
    domain logons = no
    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    server role = member server
    workgroup = MYDOMAIN
    realm = MYDOMAIN.LAN
    security = ADS
    client use spnego = yes
    cache directory = /var/tmp/.cache/.samba
    local master = no
    domain master = no
    preferred master = no
    ads dns update = yes
    winbind cache time = 7200
    winbind offline logon = yes
    winbind enum users = yes
    winbind enum groups = yes
    winbind nested groups = yes
    winbind use default domain = no
    winbind refresh tickets = yes
    idmap config MYDOMAIN: backend = rid
    idmap config MYDOMAIN: range = 20000-90000000
    allow trusted domains = no
    client ldap sasl wrapping = plain
    template shell = /bin/sh
    template homedir = /home/%D/%U
    netbios name = FREENAS
    pid directory = /var/run/samba
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1

[temp]

    path = /mnt/zfs03/temp
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    vfs objects = zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare

Domain is bound probably. wbinfo -u und wbinfo -g returns users. User logon authentication and authorization works from my perspective. Checking the trust secret for somain via RPC (wbinfo -t) suceeds.

To fully disclose problems with active directory issues, I'm testing with BOTH local and domain users.

Hardware

• AsRock C2750D4I
• Intel Octa Core Avoton C2750
• 16GB DDR3 1600 ECC Ram
• 4 WD Red Pro 4TB (2 stripped mirrors)

Any idea what causes the problem and how to solve id?

 

[nojohnny101]

are you using different share services to access the same dataset?

this is a no-no in FreeNAS as it can cause permissions problems.

Additionally, what were the original permission settings of the dataset that you are doing this on (screenshots if you can)?

 

[funnyprinter]

Added screenshots and information to the additional post.

No, right now I'm stuck configuring smb via cifs thus I have not started configuring afp. However I need to access the same dataset from windows and mac.

Why do different sharing services cause permissions problems?

Original permission settings were rw for user + group. The funny thing ist that the same user can change the file from mac, but not from the windows. this is really confusing me. From my mac I can change the file, close connection, connect with the other user and change the file. However from windows it fails in the described error.


Which sharing service you d recommend for an mixed environment with macs and windows. afp is not supported by windows. NFS or SMB?

 

[nojohnny101]

here is a quote from the manual:

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.

I'm not sure why it is giving you that strange behavior, I mean it should be consistent. Then again if could be a result of what I mentioned above (not sharing the same dataset with two different sharing services).

Which sharing service you d recommend for an mixed environment with macs and windows. afp is not supported by windows. NFS or SMB?

CIFS is supported well on both macs and windows. I would go with that.

 

[anodos]

Which sharing service you d recommend for an mixed environment with macs and windows. afp is not supported by windows. NFS or SMB?

SMB (CIFS in the webgui)

Try enabling the following VFS objects on all of your samba shares: "fruit", "catia", "streams_xattr". Since you're having problems, you should use the webgui to reset permissions to sane defaults by cycling the "apply default permissions" checkbox on your shares.

Is this an AD environment? If so,

• post following contents of /usr/local/etc/smb4.conf
• verify that your AD users and groups appear when you type "wbinfo -u" and "wbinfo -g"
• verify that trust relationship is set up properly by typing "wbinfo -t"

BTW, you should migrate away from Server 2003 if at all possible. It is a terrible security liability and should be avoided.

 

[funnyprinter]

Enabling the following VFS objects on all of your samba shares: "fruit", "catia", "streams_xattr".

VFS objects enabled are fruit, catia, strams_xattr and aio_pthread now. Apply default permissions is also active. Problem still occurs.

Since you're having problems, you should use the webgui to reset permissions to sane defaults by cycling the "apply default permissions" checkbox on your shares.

Done. Problem still occuring. Have not changed permissions with chmod or chown. Since I'm aware of the problems, I also tried reparing with winacl. Neither shows any affect.

Is this an AD environment?

It is an ad environment. Added config above. Ad integration seems to work fine. Trust suceeds, users are shown and authentication works. I'm double testing with local and domain users. Both do have the problems.

BTW, you should migrate away from Server 2003 if at all possible. It is a terrible security liability and should be avoided.

Regarding Windows Server 2003, I do now its deprecated, however the problem lies in if possible. It is not possible in reason of software I need only available for it.

 

[funnyprinter]

I'm not sure why it is giving you that strange behavior, I mean it should be consistent. Then again if could be a result of what I mentioned above (not sharing the same dataset with two different sharing services).

As mentioned above, only cifs/smb is enabled. afp for now is fully disabled. I'm aware of right problems, had the problems in an old installation and thus avoided it.

Why use AFP in addition to SMB in an mixed environment with macs and windows?

CIFS is supported well on both macs and windows. I would go with that.

yes and no, somethat

CIFS ist supported on both, yes. BUT, there are several reasons why AFP may be interesting in addition to SMB:

1. Unstability in SMB protocoll, especially smb on mac (smb2 was a mass, smb3 may be better),
2. higher features (server side search) and
3. AFP has much higher speed then SMB.

Just did an speed test, to give you an impression:

SMB: read 20MB/s write 20MB/s
AFP: read 105 MB/s write 105MB/s
ZFS Replication about 110MB/s

For testing I added a separate dataset for mac and shared it through afp. Tested in serial (not random) reading and writing with 5GB junks! Adding hardware configuration above, but seeing the AFP and ZFS replication speeds the 1Gb LAN seems the limiting factor.

However this is another problem. Before looking at this, smb must work stable.

 

[funnyprinter]

Ok, just did further testing. The problem is not associated to windows.

Editing files through mac via smb seems to somehow lose or change the cifs permissions. This results in the weird behavior that windows clients cannot edit the files any more. However macs continue to be able to edit the files. The problem is inherent do different mac osx versions.

Code:

-rw-rw-r--  1 UserA allusers    8 Aug 29 11:52 test-by-mac.txt
-rwxrwxr-x+ 1 UserB  allusers     0 Aug 30 10:33 test-by-windows.txt*

Is it anyhow possible, to force samba to a specific permissions and ignore the permissions set on the file?

Updated the problem description above accordingly

 

[Mirfster]

Not a MAC User, but perhaps these may provide some assistance:
http://serverfault.com/questions/53...-resetting-permissions-at-deeper-folde/542284
https://support.apple.com/en-us/HT1629

 

[anodos]

Ok, just did further testing. The problem is not associated to windows.

Editing files through mac via smb seems to somehow lose or change the cifs permissions. This results in the weird behavior that windows clients cannot edit the files any more. However macs continue to be able to edit the files. The problem is inherent do different mac osx versions.

Code:

-rw-rw-r--  1 UserA allusers    8 Aug 29 11:52 test-by-mac.txt
-rwxrwxr-x+ 1 UserB  allusers     0 Aug 30 10:33 test-by-windows.txt*

Is it anyhow possible, to force samba to a specific permissions and ignore the permissions set on the file?

Updated the problem description above accordingly

Oh. It looks like you've configured the permissions type for your samba share's dataset as "Unix". This is known not to work correctly and is officially an unsupported configuration. You should set it to "windows" then reset the ACLs on the share via the "apply default permissions" checkbox in your share config.

 

[funnyprinter]

ok ... super weird ... updating the zfs permission type, resetting permissions did not solve the issue. However recreating the hole dataset seems to have solved the problem. Gonna do some more tests.

However, editing a file on mac changes the owner. Editing on windows doesn't. However accessibility seems to be ok though.

 

[nojohnny101]

yes and no, somethat

CIFS ist supported on both, yes. BUT, there are several reasons why AFP may be interesting in addition to SMB:

1. Unstability in SMB protocoll, especially smb on mac (smb2 was a mass, smb3 may be better),
2. higher features (server side search) and
3. AFP has much higher speed then SMB.

Just did an speed test, to give you an impression:

SMB: read 20MB/s write 20MB/s
AFP: read 105 MB/s write 105MB/s
ZFS Replication about 110MB/s

I haven't seen any problems with #1 you mentioned. are you up to date on Mac OS X? you're correct about #2 but regarding #3 I found when I did my testing (I originally setup all shares as AFP but then later changed the SMB) that the speeds were comparable.

20MB/s read/write seems slow for SMB on a mac. I'm getting 80MB/s - 100MB/s read/write. So much is dependent on environment though so I can't begin to say why.

Glad you got it sorted out.