Unsolved
This post is more than 5 years old
2 Posts
0
2754
March 14th, 2014 06:00
Copying Files from NFS to SMB share on MAC leaves files greyed out in Finder
I am copying directories from an NFS share to a SMB share on the same Isilon cluster using the MAC finder to copy/paste
The copy starts and then depending on the version of MAC OS the following happens
10.9 - The copied directory is greyed out in SMB share window and the modified date on the directory is set to 24 January 1984.
If I SSH to the Isilon and check the directory I can see files in it and if I mount the SMB share on a Windows box again I can see the files with the correct date information
10.8 - The copy progresses as expected and the files appear on the Isilon but at the end of the process the files are deleted again. Basically I think that Finder is not completing so it tidys up after itself and removes the copied files
I have looked at the ACLs on the directory involved and it seems to have the correct setting to allow me access (which I can from Windows 7)
These ACLs exist on both the source and destination files, and I can access the source file from both NFS and SMB mounts
ACLs shown below for both Domain user and the local NFS user that has access
0: user:DOMAIN\craign allow inherited dir_gen_read, dir_gen_write, dir_gen_execute, std_delete, std_write_dac, delete_child, object_inherit, container_inherit,inherited_ace
1: user:print allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit,inherited_ace
Has anyone seen this behaviour before or have any idea how to get round it.
I am thinking of making the SMB share accessible via NFS and then doing a copy from NFS share to NFS share to see if that fixes it
Thanks
peglarr
2 Intern
•
99 Posts
0
March 15th, 2014 07:00
Several things going on here...first, beware of the SMB2 stack on Mountain Lion (10.9.x). There are bugs aplenty, even in 10.9.2, some of which directly affect SMB shares and files' behavior. If you need SMB access from a Mac running 10.9.x, it may be worth your while to revert to SMB1, or ignore SMB completely and run NFS.
But I am curious why you are copying files from an NFS export to an SMB share at all - why not just expose the same Isilon directory via SMB to the same host that has the NFS export, instead of copying data? Many Isilon users expose the same directory via several protocols simultaneously. Now, I'm sure your Isilon rep is delighted that you are consuming 2x the space on your cluster
but it's entirely unnecessary just to access the same files.
Having said that, you may have very good reason to duplicate content - so carry on, but again beware of 10.9.x with SMB2. Numerous bugs seen by the community, several not fixed by Apple. As is Apple tradition, they say "they are aware" but refuse to reveal a fix date or release vehicle. Good luck!
BernieC
76 Posts
0
March 15th, 2014 08:00
24 January 1984 is a special date for the Mac Finder. Any directory set to that date will be grayed out and inaccessible for normal user access.
Apple sets this date as the default creation date in this NFS to SMB copy scenario. Isilon honors it, but Microsoft SMB servers don't.
I have reported this issue internally to Isilon and a fix is in the works. In the meantime there is a tool on the Mac called SetFile which will allow you to set the create date to something else for these SMB directories.
Isilon shouldn't have this problem with files anymore, just directories. And, for the curious, this special date the Finder uses is also the date set on an application bundle's directory when you install apps from the App Store. 24 January 1984 was the date the original Mac was introduced to the world.
If SetFile isn't an option, something like A Better Finder Rename may work as well.
ncraig4
2 Posts
0
March 19th, 2014 02:00
Hi
Thanks for the responses
Reverting to SMB1 didn't seem to make any difference the copied files still remain greyed out in the finder window yet are accessible from a Windows machine or over NFS in the new location
Beginning to find the SMB from the MAC has a few interesting challenges
I have reverted to exposing the new location via NFS and allowing certain clients only to mount to allow the copying process
To satisfy curiosity
The data is copied from one location to another for archiving. The original location is the working area of the entire team in question, once the work is complete the data is then archived (copied to the a new location) and once secure and verified is then deleted from the original working location. So in the end we only retain one copy of the data so no really happy salesman.
It is slightly antiquated but the team in question have found that it works for them
The reason for wanting SMB access only to the archive area is that there are multiple client types that can access it some of which are old Windows machines that don't have particularly good NFS client implementations.
user_e72e35
1 Message
0
December 1st, 2019 08:00
SetFile -d 12/01/2019 folder_name would make it non-grayed out.
Or use this command:
ls -d */ | xargs -I {} SetFile -d 12/01/2019 "{}"