CIFS share with windows ACL not permitting applications to write

[Eniac74]

The background
I thought I finally had solved all my permission issues, when all users hade access to the correct datasets and the denied ones were invisible. However, when trying to start using the datasets, e.g. changing a Word file showed that everything was not there, because the applications do not seem to have write/change permission.

I have read the following thread here on the forum, and tried to apply its solutions, but no.

https://forums.freenas.org/index.ph...lications-write-permission.18854/#post-104151

The set-up
Basically, I have

Share: CIFS
ACL: Windows​

All the permissions have been set through Windows7, running on a Macbookpro (MBP). Accessing the files through the same MBP, but using OSX instead of Win7.

The problem
As said, as far as read, write and creating new files, the permissions work perfectly, but when I try to save a file through an application (Word more specifically) something hits the fan (the file's name is originally FreeNAS.docx):

1. Unable to save the file, see screenshot 1
2. The file changes name to FreeNAS2 (without file suffix) in the Word window header.
3. The original file on FreeNAS changes name (but contents are the same), see screenshot 2
4. Having left the whole thing overnight, I again rename the file FreeNAS.docx
5. Trying to open the file anew, something has changed (worked yesterday), see screenshot 3

As for permissions I had originally set User1 with Full control and no group as owner and no Everyone, i.e. only User1 has permission to do anything. I first thought that this perhaps caused a problem for applications as they perhaps were using root or wheel (do they?), but apparently no. Because I created a new dataset ("Test"), used for the five step test above, where

[root@FreeNAS]# ls -ld Test
drwxrwxrwx+ 2 root wheel 6 Mar 29 13:00 Test
[root@FreeNAS]# getfacl Test
# file: Test
# owner: root
# group: wheel
owner@:rwxpDdaARWcCo-:fd----:allow
group@:rwxpDdaARWcCo-:fd----:allow
everyone@:rwxpDdaARWcCo-:fd----:allow

For full disclosure, the dataset Test is actually located a few levels down in the structure, but where User1 has Full control all the way down, in case this could have any effect.

The questions
I want User1 to have sole access to dataset Test, but of course would also like the applications used by User1 to be able to rwx the very same dataset.

Two questions:
1. What is the problem and what needs to be altered in order for my applications to be able to work with the files correctly ?
2. How come the application manages to change the file's name, but apparently does not have any permission to save the file?

 

[Ericloewe]

Make sure you haven't set Everyone to deny.

 

[Eniac74]

Thanks for the swift response. Unfortunately (well, fortunately perhaps) I have not set Everyone to deny, but have rather granted that user the same Full control as those of owner and group, see the getfacl output (reproduced below).

owner@:rwxpDdaARWcCo-:fd----:allow
group@:rwxpDdaARWcCo-:fd----:allow
everyone@:rwxpDdaARWcCo-:fd----:allow

(On a side note I did do exactly what you referred to on my very first attempt when trying to hide datasets for non-owners, but hopefully learnt my lesson there and then as exactly nobody was allowed access :)).

 

[Eniac74]

UPDATE - narrowing in on problem

I logged out of OSX and logged into Win7 (bootcamp on MBP) and tried to do the same thing, i.e. change the file and save it. Well, the test was not identical as I do not have Office installed on the Win7 partition, but gave it a go with Wordpad (that is the name of the embedded word application is it not?) and it managed to save the file to the FreeNAS server.
Having now logged in to OSX anew, the file is there with the updated info (last saved as well as contents of file). However, I am still unable to alter the file with Word in OSX and subsequently save it to the FreeNAS server, as I still get the same error messages and changes as described above.
Furthermore, on Win7 I have different credentials for my user than on FreeNAS, whereas on OSX I have identical (both user name and password), so does not seem to be that.

So, the problem seems to be with FreeNAS/OSX/Windows ACL rather than permissions per se. I remember reading somewhere in the manual about enabling Netatalk in order to ease the co-existence of both AFP and CIFS shares, but as I have shared everything using CIFS only thought this was not needed/applicable. Anybody that could shed some light on that?

 

[Eniac74]

UPDATE 2 - found culprit?
(hoping this could add some clarity to other people's problems)

OK, so I have come across a lot of threads where people have problems connecting to Windows servers with Apple's version of Samba, and there seems to have been different workarounds in previous versions of OSX. See this page for an example:

http://arstechnica.com/civis/viewtopic.php?f=19&t=1253789

I have tried the following ways to remedy my problems (in all cases connecting by using cmd+K in Finder):

1. smb://FreeNAS
2. cifs://FreeNAS
3. smb://FreeNAS:139

But to no avail, unfortunately. I also tried this with an older MBP, running OSX 10.6.8 (Snow Leopard), where the other one runs 10.10 (Yosemite), but no difference.

So instead I tried creating a new dataset and setting up an AFP share instead, where the all choices are set to AFP/Mac. This works. So, right now I am inclined to believe that Windows/SMB/OSX is not really doing the tango (or rather not the samba). Given that Apple moved over to SMB (instead of AFP) for future communication with the introduction of Mavericks, my hope and expectation was that I could use a Windows/CIFS set-up in FreeNAS in order to make it future proof. No such luck it seems.

I would be very interested if anybody could corroborate my findings/suspicions. Or even better, prove me wrong.

 

[Eniac74]

UPDATE 3 - final one.

So, I re-read the manual and in table 11.3a there is a line 'Use syslog' where two files are mentioned that should log authentication failures. However, I found nothing of interest in those files, other than lines related to this reported bug:

https://bugs.pcbsd.org/issues/8044

I made another test on a dataset where all choices were set to Mac/AFP, and I then made a CIFS share for. I then shut down the AFP service and started the CIFS ditto. This did not help, as the same problem persisted, so everything points to the CIFS service, i.e. the SMB protocol to my understanding.

Furthermore, I have tried repairing permissions on my MBP, see the following thread:

https://discussions.apple.com/thread/4669888?q=smb share

But again, no change. So, after having searched the internet some more and counseled an OSX aficionado I have landed at the suspicion that there is some proprietary twist to Apple's SMB3. So...I reverted to using AFP/Mac for the FreeNAS setup (after having first upgraded to OSX 10.10.3 to see if that helped the CIFS setup).

Hopefully there will be some clarification down the road on this issue, but for now it just is not worthwhile to spend more time on finding a working solution with SMB. Maybe Apple should spend some more time though...