This post is more than 5 years old
18 Posts
0
7459
Mavericks OS X 10.9 / SMB2 / Finder : cannot rename
Hi everybody,
We are using OneFS 6.5.5.22 :
Isilon OneFS v6.5.5.22 B_6_5_5_244(RELEASE) installed on all nodes.
Disk_Firmware_1.6 - installed
patch-111687 - installed
patch-113108 - installed
IsiFw_Package_v8.3 - installed
patch-113513 - installed
MacOS X 10.9 (Mavericks) is now using smb2 by default.
If I connect to an smb share, I cannot rename any folder at the root of
the share using the finder (the contextual menu does not propose it,
same thing when I click on the name). I can do it using mv in
/Volumes/myshare with a terminal.
If I force smb1 using smb_neg option in /etc/nsmb.conf, everything is
working correctly (with very bad performance, see
https://groups.google.com/forum/#!topic/isilon-user-group/YU5yXmpTax0).
Apple told us to ask Isilon, and Isilon support told us to patch our
installation with various things that didn't help. Now, they're
suggesting an upgrade to 7 because "Isilon did fix lots of things".
We've just tried a VMWare Virtual Nodes 7 images, without success.
It looks to me quite obvious that this is an OS X problem (it works in
the terminal, not in the finder), but Apple does not seem to agree.
We are quite stuck here (several weeks since we opened the case).
Besides the fact that Isilon support didn't even try to reproduce the
problem in their labs (to confirm that this is not a problem on their
side), do you have any feedback on this behaviour ?
I've also posted this question to the Isilon User Group : Google Groups
Daniel Pritts from the user group reproduced the problem on 7.0.2.4.
It seems that SMB2 situation is quite messy on 10.9 right now.
I just need a CLEAR status from EMC/Isilon on this problem : where is the problem, is it working on, is there an ETA for the resolution ?
Jean-Baptiste
BernieC
76 Posts
0
January 13th, 2014 10:00
Originally I thought that the problem had something to do with setgid being set on the directory (chmod 2770), but that isn't it. It's actually, the lack of std_delete that trips up the Mac. What you're seeing above is a synthetic ACL that's derived from the Posix mode bits on "dirtorename". The ACEs for user:jbdenis and group:sis allows for delete_child, but not for std_delete. 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. The command line, as we've seen, works just fine, as does a Windows client.
Forcing the Mac to SMB1 by using cifs:// in the server URL also works, with performance impacts.
I'm certainly leaning towards Apple bug, 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. Something like this could be done:
mkdir -p /ifs/test/myshare/dirtorename && \
chown jbdenis:sis /ifs/test/myshare2/dirtorename && \
chmod +a user jbdenis allow generic_all,object_inherit,container_inherit /ifs/test/myshare2/dirtorename && \
chmod +a group sis allow generic_all,object_inherit,container_inherit /ifs/test/myshare2/dirtorename && \
chmod -a# 2 dirtorename
The only thing that does not get is setgid on the group, but the ACL will be inherited by new subfiles and subdirectories.
BernieC
76 Posts
1
January 10th, 2014 11:00
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
jbdenis
18 Posts
0
January 12th, 2014 14:00
Hi Bernard,
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" =)
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
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.
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.
peglarr
99 Posts
1
January 13th, 2014 08:00
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.
jbdenis
18 Posts
0
January 13th, 2014 08:00
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.
jbdenis
18 Posts
0
January 13th, 2014 09:00
> 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.
peglarr
99 Posts
0
January 13th, 2014 09:00
Here is one blog post in which a person mentioned renaming files and his workaround was to use the cifs: prefix instead of smb:
http://cammodude.blogspot.com/2013/10/os-x-109-mavericks-workaround-for-smb.html
Your case one that illustrates a larger Apple problem; the relationship of the Finder, SMB2 and permissions handling therein. Renaming is merely updating file metadata, and the Finder has problems dealing with the root of an SMB2 share and the saving of files. In your case, you are saving metadata. You are also using LDAP which many of the others don't, but that is about authentication, not necessarily SMB2/Finder permissions handling, which is the core of the Apple problem (pun intended)
The advice the Isilon support people gave you is sound.
You yourself admitted this in your original post:
"It looks to me quite obvious that this is an OS X problem (it works in the terminal, not in the finder),"
Bingo.
Your best resource at this point, in my opinion, is to use the known workarounds or place your business emphasis (read: customer pressure) towards Apple support. It is there in which you will solve the problem. If it's any consolation, you have quite a bit of company.
jbdenis
18 Posts
0
January 13th, 2014 10:00
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 ?
mattashton1
93 Posts
0
January 13th, 2014 11:00
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
jbdenis
18 Posts
0
January 13th, 2014 11:00
> 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.
BernieC
76 Posts
1
January 13th, 2014 13:00
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:
Note that the permissions I had not allowed were full control, delete, and take ownership.
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!
jbdenis
18 Posts
0
January 13th, 2014 23:00
> 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.
BernieC
76 Posts
0
January 14th, 2014 10:00
Hi jbdenis,
I will update the SR, and I've also posted some details about this thread to the Apple Discussion Forum, here.
Thanks!
jbdenis
18 Posts
0
January 16th, 2014 05:00
Thank you
jbdenis
18 Posts
0
March 9th, 2014 05:00
10.9.2 does not seem to correct this behaviour. Do you have any news from Apple on this matter ?