When you copy a file from one directory to another, it inherits inheritable permissions from the directory you copy it to. When you move a file, it retains permissions, because a move is just a relink of the file. I'm seeing the same behavior on 7.0.2.12 and 7.1.0.6 here with a Mac 10.10 SMB2 client. I suspect 10.9 will work just the same. I am also curious what a Windows server does (it should behave the same).
I start with /ifs/README.txt as the file:
bernie-7106-1# ls -le /ifs/README.txt
-rw-r--r-- 1 root wheel 1031 Nov 12 01:50 /ifs/README.txt
As I suspected, it works just the same on Windows. Files moved from one directory to another retain permissions, but files copied inherit permissions from the directory to where they are copied.
By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.
With a Windows Server, the only stipulation there is that if you move a file from one volume, say a share on a D drive, to a share on an E drive, it can't just be a re-link, it's a copy and then remove. Because an Isilon cluster is all one volume this doesn't apply. The same behavior can be expected when moving files within a volume on a VNX or between volumes on a VNX, between filesystems the system must actually copy then remove, so the permissions are inherited, within a filesystem it's just updating an inode.
We discovered that the users that had the permissions issues were users using Mac OSX 10.8.5 and we had some users that was on Mac OSX 10.10 was not effected. So we need to upgrade all the users to Mac OSX 10.10.
We discovered that the users that had the permissions issues were users using Mac OSX 10.8.5 and we had some users that was on Mac OSX 10.10 was not effected. So we need to upgrade all the users to Mac OSX 10.10.
I will admit that "users that had the permissions issues" statement seems a bit confusing and I am curious what exactly that means. Other than the fact that 10.8.5 doesn't support SMB2 and 10.10 does, there shouldn't have been major differences in the way permissions work between the two. There was a bug in 10.9.x that may have applied (it dealt with the ability to rename directories), and that was fixed by Apple in 10.10. Maybe a new thread discussing the 10.8.5 issue would be a good idea.
Possibly. I don't follow all the inner workings of any of the difference environments super close, but I was able to find some blogs out there expressing the very issue I was making but it was with NetApp and it was OSX 10.8 that was in question.
BernieC
76 Posts
0
April 1st, 2015 08:00
When you copy a file from one directory to another, it inherits inheritable permissions from the directory you copy it to. When you move a file, it retains permissions, because a move is just a relink of the file. I'm seeing the same behavior on 7.0.2.12 and 7.1.0.6 here with a Mac 10.10 SMB2 client. I suspect 10.9 will work just the same. I am also curious what a Windows server does (it should behave the same).
I start with /ifs/README.txt as the file:
bernie-7106-1# ls -le /ifs/README.txt
-rw-r--r-- 1 root wheel 1031 Nov 12 01:50 /ifs/README.txt
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow file_gen_read,file_gen_write,std_write_dac
1: group:wheel allow file_gen_read
2: everyone allow file_gen_read
I'm going to copy or move this file to /ifs/data/blah:
bernie-7106-1# ls -led /ifs/data/blah
drwxrwxr-x + 2 root wheel 0 Apr 1 08:14 /ifs/data/blah
OWNER: user:root
GROUP: group:wheel
0: user:BERNIELAB\berniec allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
1: user:BERNIELAB\administrator allow dir_gen_all,object_inherit,container_inherit
2: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
3: group:wheel allow dir_gen_read,dir_gen_execute
4: everyone allow dir_gen_read,dir_gen_execute
When I copy the file:
bernie-7106-1# ls -le /ifs/data/blah/README.txt
-rwx------ + 1 BERNIELAB\admini BERNIELAB\domain 1031 Nov 12 01:50 /ifs/data/blah/README.txt
OWNER: user:BERNIELAB\administrator
GROUP: group:BERNIELAB\domain users
0: user:BERNIELAB\administrator allow file_gen_all
When I move the file:
bernie-7106-1# ls -le /ifs/data/blah/README.txt
-rw-r--r-- 1 root wheel 1031 Nov 12 01:50 /ifs/data/blah/README.txt
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow file_gen_read,file_gen_write,std_write_dac
1: group:wheel allow file_gen_read
2: everyone allow file_gen_read
BernieC
76 Posts
1
April 1st, 2015 09:00
As I suspected, it works just the same on Windows. Files moved from one directory to another retain permissions, but files copied inherit permissions from the directory to where they are copied.
More detail here:
How permissions are handled when you copy and move files and folders
By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.
crklosterman
450 Posts
1
April 1st, 2015 10:00
With a Windows Server, the only stipulation there is that if you move a file from one volume, say a share on a D drive, to a share on an E drive, it can't just be a re-link, it's a copy and then remove. Because an Isilon cluster is all one volume this doesn't apply. The same behavior can be expected when moving files within a volume on a VNX or between volumes on a VNX, between filesystems the system must actually copy then remove, so the permissions are inherited, within a filesystem it's just updating an inode.
~Chris Klosterman
Senior Solution Architect
EMC Isilon Offer & Enablement Team
chjatwork
2 Intern
•
356 Posts
1
April 2nd, 2015 06:00
We discovered that the users that had the permissions issues were users using Mac OSX 10.8.5 and we had some users that was on Mac OSX 10.10 was not effected. So we need to upgrade all the users to Mac OSX 10.10.
BernieC
76 Posts
0
April 2nd, 2015 07:00
I will admit that "users that had the permissions issues" statement seems a bit confusing and I am curious what exactly that means. Other than the fact that 10.8.5 doesn't support SMB2 and 10.10 does, there shouldn't have been major differences in the way permissions work between the two. There was a bug in 10.9.x that may have applied (it dealt with the ability to rename directories), and that was fixed by Apple in 10.10. Maybe a new thread discussing the 10.8.5 issue would be a good idea.
chjatwork
2 Intern
•
356 Posts
0
April 8th, 2015 14:00
Possibly. I don't follow all the inner workings of any of the difference environments super close, but I was able to find some blogs out there expressing the very issue I was making but it was with NetApp and it was OSX 10.8 that was in question.