D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-323 => Topic started by: zforum69 on September 20, 2010, 08:49:33 AM
-
Hi all I need some help with permissions on my DNS323.
I have recently reformatted my drives to ext3. I did this by copying the contents of one drive to the other using the "cp" command after reformatting to ext3. I can see all the files but I just can't work out why I can't actually delete anything using Windows.
For example I can make new directories and copy files into an existing directory "Volume_1/My Documents" fro example, but I then cannot delete them. The only way at the moment is to telnet in as root and remove them that way. However if copy files or make directories in the root direcotry (i.e. "Volume_1") I can delete them.
I'm guessing it is something to do with permissions but I can't work out why, but I am definitely no linux expert. Any ideas?
Z
-
For future reference, next time you do such en mass copy of data you should use "cp -a", which preserves file attributes such as modification times and permissions.
-
For future reference, next time you do such en mass copy of data you should use "cp -a", which preserves file attributes such as modification times and permissions.
yes, unfortunately I only realised only after it was too late. Oh well, at least I still have my files, i just can't search on modification date anymore.
Z
-
You can try assigning the onwership 'chown -R nobody:501 *' for the various directories and files and/or change the permissions 'chmod -R 777 *' on the various directories/files as well to see if that resolves your windows access issue.
-
Why not copy them again with the correct parameters?
-
cd /mnt/HD_a2 (or cd /mnt/HD_b2)
chmod -R 777 *
Will do the trick. All files created on the NAS via SMB end up with full 777 permissions.
You can optionally change the owner too. If you've created a user called "Jamie" and a group called "Users" you can do:
chown -R Jamie:Users *
-
Why not copy them again with the correct parameters?
I tried that (onto "/mnt/HD_b2") but then I get the same problem with the files on Volume_2.
Maybe I'll have to do it manually via windows explorer but that will take ages because it will have to go via the PC. It already took 18hours doing a direct copy with "cp".
Z
-
You can try assigning the onwership 'chown -R nobody:501 *' for the various directories and files and/or change the permissions 'chmod -R 777 *' on the various directories/files as well to see if that resolves your windows access issue.
I did that too and still no luck. I tried to look at the permissions and ownership of a directory that I manaually created in the root that I can delete (i.e "Volume_1/test") and one inside "My Documents" that I can't (i.e. "Volume_1/My Documents/test" and "Volume_1/My Documents") and there does not appear to be any difference. Both had full full permissions (i.e. drwxrwxrwx), and no ownership nobody:501
Is there anywhere else, maybe specifically associated with samba, that could be causing this?
Z
-
I just did another test can confirmed that copying from one drive to another using windows explorer does let me then use the files in the second drive as I expected. Copying via "cp" still has the same issue.
Copying via windows explorer is going to just take way too long. There has got to be another way.
Z
-
OK I've got some more information
If I manually map the share "Volume_1" to a drive I can do as I will. for example let's say I map it to y:\ then I can delete "y:\My Documents\test"
However if I go straight to "\\server\Volume_1\My Documents" and then try to delete "test" it fails.
I have default file permissions, that is everybody has access and can do anything.
I am totally stumpped.
Z
-
Have you set the file permissions as suggested?
-
Have you set the file permissions as suggested?
yep.
I just don't understand if I map the share to a drive letter it works. but if I reference via a UNC name it does not. I had "My Documents" mapped to the unc name "\\dns323\Volume 1\My_Documents", but now it no longer works.
Z
-
I can only assume that the credentials for the mapped drive are different to that used via the UNC path? I'm not even sure that's possible. Did you use a specific username and password for the mapped drive?
-
cd /mnt/HD_a2 (or cd /mnt/HD_b2)
chmod -R 777 *
Will do the trick. All files created on the NAS via SMB end up with full 777 permissions.
You can optionally change the owner too. If you've created a user called "Jamie" and a group called "Users" you can do:
chown -R Jamie:Users *
I actually use the following command:
chown -R nobody /mnt/HD_b2
Worked for me at least in resetting all the permissions to everyone or nobody. Able to delete just fine afterwards. Also to the OP, why not use the following command to copy the files:
rsync -v -r --ignore-existing --stats /mnt/HD_a2/files /mnt/HD_b2
PS. I have all my files needing to be backed up in a folder named "Files" on the root of the HD_a2 drive.
It makes subsequent backing up much faster.
-
Out of desperation I start to do all sorts of stuff with users and shares on the DNS just to see if I can make something changed. I even deleted all shares. After rebooting it reinstated Volume_1 and Volume_2, it obviously does not like no shares. At some point in time in all this I noticed in the putty window that all the file permissions were NO LONGER rwxrwxrwx, but I can't remember exactly what it was. Seeing this change I then proceded with the "chmod -R 777", and guess what it works now!!!
If I had the time I would try to retrace my steps in an effort to try to repeat the issue and nail down the fix, if not work out the cause. Unfortunately I only have two drives and now that it is all working I don't won't to risk my production data.
If in the future I manage to borrow a couple of sata drives I'll see if I can repeat it. Otherwise, I am just happy that it all works as it should now.
Z
-
Like I said, chown -R 777 *
;)
Perhaps you set the folder to 777, but not the files inside it.
-
Like I said, chown -R 777 *
;)
Perhaps you set the folder to 777, but not the files inside it.
To be honest now, I'm now not sure what happened. I managed to borrow a couple of SATA drives to try to replicate the problem, and of course I could not.
I Just could not replicate the same conditions. For example I could not get to a state where I could add a file or directory, but then could not delete it. All I could manage to do was to have no ability to do anything other than read it, which is what should happen. I didn't even try creating the situation where I had full access if it was mapped to a drive letter, but had problems if it was referenced by the UNC name.
As soon as I experienced unexpainable symptoms, I should have reset to defaults and reboot the NAS. After reading the forums that solution seems to fix a lot of problems. :)
Z