Mavericks OS X 10.9 / SMB2 / Finder : cannot rename

Hi Jean-Baptiste,

I think I found the SR where this issue was reported to Isilon support, and I sent a web note to the contact on that SR, which was not you.  I have not seen the same behavior internally on my own 10.9 Macs and OneFS 6.5 or 7.0.

At first guess, this looks as if Finder is misinterpreting permissions, but what I see from the customer in that other SR looks normal to me, and shouldn't cause problems for the Finder.

It would be excellent if I had some details on your cluster and client configuration so I can reproduce this.  Are your Macs and cluster joined to AD or are they authenticating with username/password (NTLM) credentials?  What are the permissions on your share, and what are the permissions on the folders in the share?  You can get those details with this:

isi smb permission list --sharename=

ls -led

I'd also like to see ls -led of the parent folder in that SMB share.

Thank you,

Bernie

Hi Jean-Baptiste,

Hi Bernard,

I think I found the SR where this issue was reported to Isilon support,

and I sent a web note to the contact on that SR, which was not you.

Indeed, I'm not managing this case on our side, but I'm trying anything

to get any valid answers besides "just patch and we'll see from there" =)

I

have not seen the same behavior internally on my own 10.9 Macs and OneFS

6.5 or 7.0.

THIS is interesting. I would be more than happy if this appears to be a

"simple" problem.

> It would be excellent if I had some details on your cluster and client

configuration so I can reproduce this.

Ok course. My colleague will collect all this information for you with

the help of the support during a webex to be sure you've got all you

need. I'll just answer quickly to your questions, maybe it'll help some

people out there.

Are your Macs and cluster joined

to AD or are they authenticating with username/password (NTLM)

credentials?

We are using LDAP, Isilon ACLs is on "Unix permissions", and we are

authenticating with username/password.

I don't have access to OS X mavericks to be sure to answer correctly to

your question (ie : real example of the problem). Let my colleague reply

in the SR, in the next 24h normally.

Thank you very much for your answer.

I also commented on this in the Google group.  This is an OSX 10.9 issue - still present in 10.9.1.  There have been numerous reports of this behavior, against many NAS platforms (including actual Windows Server) with SMB2.  The known/solid workaround is to revert to SMB1 workflow.

I don't quite understand why the community views this as an 'Isilon problem'.  Certainly, workflows are disrupted and Isilon behavior is affected, but in terms of product defect, clearly this is an Apple defect, based on all the public evidence.

Hi Bernard,

here are the answer to your last question and the steps we are using to reproduce the problem. I'm keeping this information here for everyone. Isilon support will update the SR after the webex session.

On the isilon side, using ssh :

ISILON # mkdir /ifs/test && chmod 755 /ifs/test

ISILON # mkdir /ifs/test/myshare && chown jbdenis:sis /ifs/test/myshare && chmod 2770 /ifs/test/myshare

ISILON # mkdir -p /ifs/test/myshare/dirtorename && chown jbdenis:sis /ifs/test/myshare/dirtorename && chmod 2770 /ifs/test/myshare/dirtorename

ISILON # ls -led /ifs/test/myshare/dirtorename                                                                                            

drwxrws---    2 jbdenis  sis  0 Jan 13 16:28 /ifs/test/myshare/dirtorename

OWNER: user:jbdenis

GROUP: group:sis

SYNTHETIC ACL

0: user:jbdenis allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child

1: group:sis allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child

ISILON # ls -led /ifs/test/myshare/dirtorename                                                                                            

drwxrws---    2 jbdenis  sis  0 Jan 13 16:28 /ifs/test/myshare/dirtorename

OWNER: user:jbdenis

GROUP: group:sis

SYNTHETIC ACL

0: user:jbdenis allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child

1: group:sis allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child

ISILON # isi smb share create --sharename=smb2test --path=/ifs/test/myshare

Share 'smb2test' created successfully!

ISILON # isi smb permission delete --sharename=smb2test --all

All permissions for share 'smb2test' successfully deleted!

ISILON # isi smb permission create --sharename=smb2test --account-name=sis --account-type=group --permission-type=allow --permission=full

Permission for account 'sis' on share 'smb2test' successfully created!

ISILON # isi smb permission list

--sharename=smb2test                                                                                   

SMB Share Permissions:

Sharename:      smb2test

        Account                    Acct Type  Perm Type  Permission 

        sis                        Group      Allow      Full       

If I connect to this share using OS X 10.9 Mavericks, I cannot rename the "dirtorename" folder (information panel is grayed out, nothing happen if I click on the name of the directory). I cannot rename the directory using a Windows 7 client.

Daniel Pritts, on the Isilon google user groups seems to be able to reproduce the problem on his installation.

> Certainly, workflows are disrupted and Isilon behavior is affected, but in terms of product defect, clearly this is an Apple

> defect, based on all the public evidence.

I would be more than happy to have an official statement from Isilon support and deal with other things. But we were suggested to apply patch (which we did), and even a OneFS 6 -> 7 update.  Also, why Bernard Case couldn't reproduce this problem ?

Could you give me some pointers that show people having the exact same problem ? Indeed, the public evidence you can found on smb2 and Mavericks is quite important, but I didn't really find anything like the problem I've got.

Thank you for the pointer. Not easy to spot what you're talking about, is that in the comments ?

"It looks to me quite obvious that this is an OS X problem (it works in the terminal, not in the finder),"

Indeed. Since we already opened a case at Apple and the answer was just "Contact EMC", I'm looking for an official statement or more basically, confirmation of EMC and help to make Apple accept our problem. I guess EMC has more power than me regarding Apple. I'm just insisting because I just want to have an official clear answer to show for Apple, that's all. And having a customer patch its Isilon cluster to deal with this specific problem although you seem to know that it won't do anything about it is quite... disappointing.

> If it's any consolation, you have quite a bit of company.

Do you have any opened case with Apple at the moment regarding this problem ?

To add another data point:

On a new 10.9 install and a fresh 6.5.5.23 cluster I was able to reproduce this.

smb://cluster/sharename/directory

could not be renamed but

cifs://cluster/sharename/directory

could from the same Mac.

10.6 of course was able to rename the directory since it uses SMBv1.

I did this with a local Isilon user so as to rule out any authentication issues.

Cheers,
Matt

> The Mac seems to need std_delete to be in the ACL in order for the Finder to give the user the option to rename.

Thank your for this analysis.

> I'm certainly leaning towards Apple bug,

Ok. Did Apple confirm this to EMC ? I mean, the lack of std_delete that trips up the Mac is really something the Finder should not interpret the way it does now or should the Isilon cluster show this option to the mavericks client ? The fact that Finder add its own business logic (it works from the mavericks CLI) is quite disturbing, but it seems to be the case.

> but you could adjust the chmod commands slightly to work around this behavior.

> Instead of using Posix mode bits, you'd be setting specific ACLs on the directories.

> The only thing that does not get is setgid on the group, but the ACL will be inherited by new subfiles and subdirectories.

The combined fact that we are not in our comfort zone regarding ACLs (besides POSIX) and that we allow symetric access between CIFS and NFS protocol (users could to their own chmod/chown etc...) mean that we cannot implement this solution without documenting ourselves and evaluate with care the impact on our users

Thank you again for your answer.

jbdenis wrote: Ok. Did Apple confirm this to EMC ? I mean, the lack of std_delete that trips up the Mac is really something the Finder should not interpret the way it does now or should the Isilon cluster show this option to the mavericks client ? The fact that Finder add its own business logic (it works from the mavericks CLI) is quite disturbing, but it seems to be the case.

I have not reported this to Apple, but I will.  I can confirm that I was able to reproduce exactly the same behavior against a Windows 7 SMB share, so long as I set the following permissions to be allowed on that directory:

• Traverse folder / execute file
• List folder / read data
• Read attributes
• Read extended attributes
• Create files / write data
• Create folders / append data
• Write attributes
• Write extended attributes
• Delete subfolders and files
• Read permissions
• Change permissions

Note that the permissions I had not allowed were full control, delete, and take ownership.

The combined fact that we are not in our comfort zone regarding ACLs (besides POSIX) and that we allow symetric access between CIFS and NFS protocol (users could to their own chmod/chown etc...) mean that we cannot implement this solution without documenting ourselves and evaluate with care the impact on our users

I would highly recommend that you take a look at this guide, which documents how we handle multiprotocol access and permissions mappings between ACLs and Posix mode bits.  If you implement Windows ACLs on objects, this guide will help you understand how we'll translate those into mode bits, and vice versa.

Time to go file that bug with Apple!

> I can confirm that I was able to reproduce exactly the same behavior against a Windows 7 SMB share, so long as I set the > following permissions to be allowed on that directory:

Ok, this is coherent, which is good news.

> I would highly recommend that you take a look at this guide

Yes, don't worry. The mapping system looks quite powerful, but we need to understand the different settings perfectly to be sure that we won't break anything. But I'm not sure if it's worth it (in our specific context).

> Time to go file that bug with Apple!

Very cool. Thank you for the time you spent on this matter. By the way, could you update the SR you've already intervened with ? That would help the support I think.

Hi jbdenis,

I will update the SR, and I've also posted some details about this thread to the Apple Discussion Forum, here.

Thanks!

Thank you

10.9.2 does not seem to correct this behaviour. Do you have any news from Apple on this matter ?