I am trying to move a massive number of files (80,000+; 330 GB) from a Linux machine to a NAS device. The Linux machine is used primarily as a file server. The files were created/placed on the Linux machine by the two of us in the office who are using the machine as a file server.
I have been able to copy about 200 GB to the NAS so far, including many Mac files. However, every once in a while I’ll get the following error:
Under show more details it says
All files that return that error were created or placed on the Linux machine by a Mac (Quark or Office). The files are in /home/linbox, the main home folder is /home/rhythmuser.
I took a stab in the dark and ran **gksudo nautilus **and **su nautilus **to see if that would make a difference, but it didn’t.
Is there any way to force the system to copy? It’s a home office, so there doesn’t need to be any particular permissions in place – anyone should be able to do anything to the files, so changing permissions in the entire folder would be OK too. Also, I’m not looking to delete or move the files, just copy them to the NAS.
Are you on the linux box itself copying the files? Or on one of the attached PCs or Macs dragging and dropping?
If you can get on the linux box, do this as the root user:
chmod -R a+rwx /home/linbox/*
Also, try finding the specific files that are giving the error and copying them over one by one. They may not even be actual files, or they may be corrupted. Also, if they start with a dot, the samba server on the linux box may be blocking them from file operations via smb.
I am on the Linux box itself. I figured it would be smoother that way, plus faster than routing everything through one of the machines.
Will try and see what happens …
You may be hitting on the problem – many of the files are Mac resource forks (or something), ones that start with the ._ prefix. But not all files are so named.
Since we’re switching to the NAS to host our files, I’m hesitant to skip all (what if there is another type of problem buried in the mix?).
Will try the permissions change and see what happens…
There is a “hide dot files” parameter in smb.conf that might be in play here.
Unfortunately, if you are working with a commercial NAS, you might not have direct access to the smb.conf file.
This really does sound like an issue with the Unix style of designating hidden files.
One thing you might do is to run some tests to see if those files are actually needed. Though they are used for the resource fork on non-HFS+ file systems, Mac OS X has been migrating away from using resource forks for some time now.
The problem is that it seems like OS X creates a resource fork file even when none is needed on Samba shares. So, you might be in a position where one or two files actually have useful resource forks, while 10,000 have useless auto-generated fork files.
If you don’t actually need them, then you might be able to filter them out somehow or set up a job that deletes them from the Unix side.
Here’s a six-year-old discussion on these resource files that gives an idea of their troublesome behavior.
Here’s why:
The “+/-rwx” notation you used can be provided without specifying group, user, or other. In this context, “-r” and “+r” are both legal options that indicate changes to make to the read bit, not recursiveness.
I’m going to have to digest the Mac resource issue. The new NAS is a Synology DS209 with a lot of options – from Windows to Appletalk. I’ll have to figure out what will make things run smoothest (but first I’ll have to learn a bit more about the ._ issue).