CIFS File Mask Not Working

[imhkdude]

I can't seem to figure out what I'm missing. Running V8.0.2 with CIFS enabled. Initially, I had both the file and directory masks set to 0774 (see below). I can confirm the directory mask works correctly but I noticed the file mask wasn't working.

When creating a file in a test directory, I get the following results with a 0770 file mask:

-rw-rw-r-- (664) [Windows XP client / user: mike]
-rw-r--r-- (644) [Slackware 13.1 using mount.cif / user: mike]
-rw-r--r-- (644) [FreeNAS console / user: root]

I also produced the same exact results above after removing the file mask in the CIFS services section. Per the documentation, I believe I should have gotten a 666 file mask which is default with no mask.

I know I have inherited permissions on so I checked my rights above the directory and nothing looks out of place. I have no ACLs setup or showing when the files are created.

I can verify the clients and FreeNAS server have both been rebooted per the solution in this thread.

Here is my smb.conf

Code:

global]
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    read raw = yes
    write raw = yes
    oplocks = yes
    max xmit = 65535
    deadtime = 15
    display charset = LOCALE
    max log size = 10
    syslog only = yes
    syslog = yes
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    smb passwd file = /var/etc/private/smbpasswd
    private dir = /var/etc/private
    getwd cache = yes
    guest account = nobody
    map to guest = Bad Password
    netbios name = hkd-nas
    workgroup = HKD-LAND
    server string = HKD-NAS Server
    use sendfile = yes
    large readwrite = no
    store dos attributes = yes
    security = user
    create mask = 0774
    create mask = 0774
    directory mask = 0774
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1
    aio read size = 1
    aio write size = 1


[documents]
    path = /mnt/storage/documents
    printable = no
    veto files = /.snap/.windows/
    writeable = no
    browseable = yes
    inherit owner = no
    inherit permissions = yes
    vfs objects = zfsacl 
    hide dot files = no
    inherit acls = Yes
    map archive = No
    map readonly = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
write list = mike, dawn

Any ideas or points in a different direction would be appreciated. Thanks.

 

[soeldner0815]

the same

here the same problem.

i have add in [global]

Code:

    log level = 1
    aio read size = 1
    aio write size = 1
    force create mask = 0770

but no effect.

Code:

-rw-r-----   1 user_linux  group1   2 Jan 11 14:17 Textdatei
-rw-rw-----   1 user_windows  group1   2 Jan 11 14:19 Textdatei
-r--r--r--   1 user_konsole  group1   2 Jan 11 14:23 Textdatei

after these tests i set force create mask in [folder] area to ... no effect.

gruss der Soeldner

PS: sry 4 my English

 

[kwagga]

Hi Guys,

I also have this exact same issue. The Client OS'es OSX 10.6.8 and OSX 10.7. I have tried several different settings, inheritance on, inheritance off. Assigning users to group instead of the file owners (left it as root), I gave the entire drive 777 permissions, and it seems to change back to either rw for ugo, or r for ugo... the CIFS settings are set to default file mask of 0666 and dir's at 0777.

I consider this a serious issue, my clients, where this server is located cannot work, as every second file they edit, should they reopen it, they only read permissions.

The logs are also not outputting any changes.

I'm running a ZFS mirrored group, with owner as root, and group as group1 (userx is a member of group1, and connects to the CIFS share, with authentication), the entire drive has been set to 777 with recurrence, and this random permission change is still happening.

 

[kwagga]

I was told this is the forum:


So I've found several resources, talking about permission issues as a result of .AppleDouble files, and some anecdotal information suggests enabled "no .AppleDouble" (aka turning it off) will solve the problem. But Freenas manual says this should be avoided. Any other solution?



http://support.apple.com/kb/TA20578
http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=50&t=393
http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=50&t=9853&p=46309&hilit=AppleDouble#p46309
http://blog.graceabundant.com/archives/2011/10/freenas-simultaneous-afpcifs-shares-done-neatly/
http://www.linuxquestions.org/questions/linux-software-2/appledouble-cleaning-111387/
https://discussions.apple.com/thread/2633169?start=0&tstart=0

 

[Daisuke]

The Client OS'es OSX 10.6.8 and OSX 10.7.

Why do you use CIFS with a Mac? Use AFP, problems solved.
As a side note, CIFS works perfect if you assign a specific user to a dataset. I did not do any configuration tuning or any abracadabra you guys posted above. It worked straight out of the box in Windows 7.



My NAS is named 'pluto', hence 'pluto\floren' user. Note the NAS hostname:

 

[kwagga]

The problem is, with AFP - when the client PC opens a large file, or several large files in a folder, or files from a mounted ntfs volume (correct permissions assigned) - the client will get CNID DB errors:


Then again, I only saw this when they accessed files from a NTFS volume. But the employees say it happens from other volumes as well, funny thing is, they wouldn't know what volumes are NTFS and ZFS.

I am busy converted the NFTS drives to unix format (EXT3/4/ZFS) but there is a shortage of drives from our supplier.


As for Windows 7 and CIFS, I have no problems there, it's all good.