I the following command to try and move everything from an old disk to my newly pre-cleared 3TB drive.

 

nohup mv /mnt/disk2/* to /mnt/disk8/Backups &

 

After an hour I came back only to find one directory that reports 0 byte size and when I try to enter it, I get the windows "...is not accessible. You might no thave permission to use this network resource" error.

 

How can I tell if anything is moving? Why can't I access the directory?

 

This page http://lime-technology.com/wiki/index.php/Transferring_Files_Within_the_unRAID_Server stated that moving would not create an output file but the command prompt says it is appending output to nohup.out. That said, I don't see where that file is on my flash drive. Searching turns up nothing.

 

Edit: So I had the feeling nothing was happening so I restarted the server. Upon reboot, the folder still is showing 0 bytes and I cannot access it. Unraid reports 2.8TB of 3TB free on the drive. 

 

What am I supposed to do with this inaccessible folder now? If I check the properties > Security tab in windows for said folder it tells me I do not have permission to view or edit the permissions settings.

Remove the drive from the linux command prompt.

 

Try copying from mc (midnight commander) rather than moving the files from the command prompt.  Given that the move appears to have failed you may have lost some data from the originating drive.  You're always better off running copy, then ensuring the copy worked, then removing the files from the source drive.

Thanks for the reply. It appears to be a permissions issue. When I telnet into the server I can see the directories that have been copied. For lack of a better idea, I'm currently running the permissions tool in Unraid 5 to see if that rectifies access via Windows share.

 

I'll look into using MC. On the note of copying - I would have if I hadn't already made a copy of everything on this drive on my windows system. I wasn't too concerned about losing data, just wanted the quickest way to move it.

The permissions issue exists because you're running the move/copy command from a terminal or ssh session whilst logged in as root.  When you do this the directories/files are owned by root so the default user (nobody which belongs to the group users) doesn't have permissions to access the files. 

 

If you move files using ssh/telnet via the cli or MC you need to run the permissions tool to set the permissions properly.  There is a cli equivalent (chown -R nobody:users path/to/files) but I think the default permissions have changed in unRAID 5RC10 and I'm not sure what the command would be.  It's easiest to run the permissions tool, although that will reset the permissions for all files on the array so it will probably be slower.

Run "newperms /path/to/file/or/directory/"

That would have saved me some time last night In the end, running the tool has granted me access to the copied files.

 

Why is it that permissions are an issue at all when copying from one disk to the other?

 

I'll try MC next and at least I know what to do if the issue arises again. Just haven't experienced this prior to Unraid 5.

 

Edit: I vaguely remember looking at MC once before but I'm not sure I realized how to use it. Knowing that I can 'cheat' by using my mouse... using MC is a nobrainer for these types of tasks! 

 

Why is it that permissions are an issue at all when copying from one disk to the other?

 

 

The reason that the permissions issue exists is because of the user (or perhaps it's easier to think of it as "context") which is being used to move the files.  Moving or copying as the root user, from a security perspective, should re-assign the permissions. 

 

The root account on *nix, or administrator account within Windows shouldn't be used as regular login accounts.  They simply have too many rights to be considered safe (from a security perspective)

 

As far as I know unRAID's array file system wasn't designed with the idea that users would regularly manipulate files on the array from the CLI or any sort of interactive logon, but would do such things from a remote system.  And if you move/copy files on the array from a remote system you don't encounter this problem.