CIFS shares and MS Excel for MAC

[BlazeStar]

Using FreeNAS 9.3

I'm having a lot of issues with MAC users, more specifically with Excel documents.

Basically, if a user opens up an Excel file on the network, then it's impossible to save it from Excel.
The user will get a "Microsoft Excel cannot access the file" error.
Also some temporary files will be created and not deleted in the folder where the file is, such as "C94A3000"

So we always have to "save as" on the desktop, then drag the file in the right network folder and overwrite it, and get rid of the pesky weirdly named temporary files.

As you can imagine, this is highly annoying and counter productive.

Users here use OS X 10.10.2
All shares are CIFS

We mount them using one of the two "methods" :
1) With the GO TO > Network feature in the finder, then typing smb://XXX
2) In the finder window, just clicking on NAS icon in the "shared" section in the left pane.
Both methods have the same end results (problem described above)

I've been trying to find a solution and post on the Apple Support forums, up to now here are some of the pointers :

• Update to the latest version of everything > OS X and Office are all latest versions, as well as FreeNAS
• Make sure file permissions are OK on the network > checked and everything is fine
  • We use Windows style permissions and with GETFACL everything looks perfect
• I've read various articles about same UID and and a .TemporaryItems hidden folder... it appears that every time a MAC MS Office user opens a file on a shared folder, it will create a .TemporaryItems folder on the root of the share... but then only the first user who has done that has access to this folder, because the folder will be created (in theory) with read/write access only for that user.

So about that last point :

I do see the .TemporaryItems folder on the root of the share :

Code:

getfacl .TemporaryItems/
# file: .TemporaryItems/
# owner: BlazeStar
# group: BlazingGroup
            group@:rwxp-daARWc---:fd----:allow
            owner@:rwxpDdaARWcCo-:fd----:allow

Also, I figure it's irrelevant but the UNIX style permissions are also good :

Code:

ls -lha
total 143
drwxrwx---+  3 BlazeStar  BlazingGroup       4B Nov 18  2014 .TemporaryItems/

So there again the permissions seem to be alright...

So I'm very puzzled about this and I'd like help on that matter please!

 

[anodos]

Have you tried using "Veto Files"?

veto files (S)
case sensitive option is applicable in vetoing files.

One feature of the veto files parameter that it is important to be aware of is Samba's behaviour when trying to delete a directory. If a directory that is to be deleted contains nothing but veto files this deletion will fail unless you also set the delete veto files parameter to yes.

Setting this parameter will affect the performance of Samba, as it will be forced to check all files and directories for a match as they are scanned.

Examples of use include:

; Veto any files containing the word Security,
; any ending in .tmp, and any directory containing the
; word root.
veto files = /*Security*/*.tmp/*root*/

; Veto the Apple specific files that a NetAtalk server
; creates.
veto files = /.AppleDouble/.bin/.AppleDesktop/Network Trash Folder/



Default: veto files = No files or directories are vetoed.

 

[BlazeStar]

No I have never tried veto files.

How would I apply that in FreeNAS ?

 

[anodos]

No I have never tried veto files.

How would I apply that in FreeNAS ?

Add as an auxiliary parameter for your share's config. (not the global CIFS config).

 

[BlazeStar]

Add as an auxiliary parameter for your share's config. (not the global CIFS config).

Why not the CIFS config?
I've got this problem on all shares!

Also what's the parameter I have to add?

 

[BlazeStar]

Just bumping to see if anyone could help

 

[anodos]

Why not the CIFS config?
I've got this problem on all shares!

Also what's the parameter I have to add?

Note that the documentation for the above parameter that I quoted states "veto files (s)" that means the parameter is applies to shares. If it had a "g" next to it, you could use it as a global parameter. I believe you can just add the auxiliary parameter "veto files = /.snapshot/.windows/.mac/.zfs/.TemporaryItems/" to your share. The default share definition in freenas already contains a "veto files" line and so I'm not sure what the effect of entering a second "veto files" line will do.

Alternatively you can quickly and temporarily test the effect of vetoing ".TemporaryItems" as follows: use vi to append ".TemporaryItems/" to the "veto files" line of one of your share's definitions. Then type "service samba-server restart".

 

[BlazeStar]

Note that the documentation for the above parameter that I quoted states "veto files (s)" that means the parameter is applies to shares. If it had a "g" next to it, you could use it as a global parameter. I believe you can just add the auxiliary parameter "veto files = /.snapshot/.windows/.mac/.zfs/.TemporaryItems/" to your share. The default share definition in freenas already contains a "veto files" line and so I'm not sure what the effect of entering a second "veto files" line will do.

Alternatively you can quickly and temporarily test the effect of vetoing ".TemporaryItems" as follows: use vi to append ".TemporaryItems/" to the "veto files" line of one of your share's definitions. Then type "service samba-server restart".

Hi !

Thanks for your feedback.

I added the following line to a share' auxilary parameter

Code:

veto files = /.snapshot/.windows/.mac/.zfs/.TemporaryItems/

Then restarted samba service.

And I still have the same problem :(

http://snag.gy/jvixu.jpg

 

[anodos]

Hi !

Thanks for your feedback.

I added the following line to a share' auxilary parameter

Code:

veto files = /.snapshot/.windows/.mac/.zfs/.TemporaryItems/

Then restarted samba service.

And I still have the same problem :(

http://snag.gy/jvixu.jpg

At this point I'd probably be doing googling and making random guesses (since I don't use or administer macs). Perhaps you should try the samba mailing list.

 

[BlazeStar]

I found the answer !!!!!

Man did I loose time with this.

I ended up re-installing from scratch and reconfiguring FreeNAS completely with different user names just to make sure and the problem would still come back!!!

In the end, I fixed my problem when I ended up on this post :
https://discussions.apple.com/thread/6613714?start=0&tstart=0

I was mounting my shares from Finder with:

Code:

smb://file-server-IP/share

Now I mount them like so:

Code:

cifs://file-server-IP/share

AND IT SOLVED MY PROBLEM!

What a glorious day.

I'm posting this for posterity, hoping someone with the same problem will not waste tens of hours on a problem simple as this.

Bottom line, if you're using OS X 10.10 or +, do not mount with SMB, mount with CIFS.

 

[anodos]

I found the answer !!!!!

Man did I loose time with this.

I ended up re-installing from scratch and reconfiguring FreeNAS completely with different user names just to make sure and the problem would still come back!!!

In the end, I fixed my problem when I ended up on this post :
https://discussions.apple.com/thread/6613714?start=0&tstart=0

I was mounting my shares from Finder with:

Code:

smb://file-server-IP/share

Now I mount them like so:

Code:

cifs://file-server-IP/share

AND IT SOLVED MY PROBLEM!

What a glorious day.

I'm posting this for posterity, hoping someone with the same problem will not waste tens of hours on a problem simple as this.

Bottom line, if you're using OS X 10.10 or +, do not mount with SMB, mount with CIFS.

File locking is handled differently in SMB1 and SMB2/3. Using CIFS:// forces the Mac smb client to downgrade to SMB1. Sounds like OSX implementation of SMB2 is somewhat broken. Might be some features they're incorporating for SMB3 compatibility. Odd.

 

[BlazeStar]

File locking is handled differently in SMB1 and SMB2/3. Using CIFS:// forces the Mac smb client to downgrade to SMB1. Sounds like OSX implementation of SMB2 is somewhat broken. Might be some features they're incorporating for SMB3 compatibility. Odd.

For now it does the trick for me... it became a nightmare to always have to save on desktop then drag and overwrite de file.

But I'm wondering... are there any downsides to be using SMB1 in such a manner?

Also, the weird thing is that file sharing would never cause any problem, except for - very specifically - Excel files. Everything other kind of file or program worked perfectly!

This fixes it, I hope it doesn't have too much disadvantages...