Unable to delete folders/files - permission denied

I am unable to delete approx 50 folders off my share - access denied.  I’ve spent a couple of hours trying everything I can think of - rebooting NAS, rebooting computer, scanning the volume for errors, attempting to change permissions on the folders, renaming folders, etc.   Please advise.

Problem occurred after doing a USB backup to the NAS.  The job seemed to stall after several hours, and then I got an internal server error when trying to access the NAS.  There was still drive activity, so I just let it run overnight, but I was unable to log back into the NAS in the morning (internal server error).  So I had to reboot, but now I have files and folders that I can not delete, move, copy, etc.

I’m not sure if this is what’s wrong, but I have found that there is a bug with moving files to a USB drive were the permissions get changed.  So if you copied or moved the files to a USB then back again the permissions maybe set wrong.

The best thing to do is to ssh into the EX4 and check the permissions.  If they are not correct then use:

chmod -R xxx (were “xxx” is the correct permissions)

So if you have a folder named “MyFiles” use

chmod -R xxx MyFiles 

This will change the permissions of all the files in that folder.

Thanks for the suggestion and the speedy response.  Wow, that was fast!  I’ll give it a shot.  I was using cygwin to try to change the permissions, but I was getting permission denied doing that.   I’ll try ssh.

I was able to access the NAS via ssh last night.  I think I found the volume and files/folders under mnt directory, but before I make any changes, I wanted to get more information on what I should be looking for.  The permissions were wide open for everything except the current directory.  I am not in front of my computer at the moment but can give exact details later, if needed, to determine if there is an issue and how to correct it.

I can try to changing permissions and ownership, but before I do, I wanted to make sure that I don’t make matters worse or cause other problems in the process.

CannotDelete1.png

Above shows some detail of the issue that I am having.  I can not remove directory  x or subdirectory y.

Below shows the contents of directory y which I am unable to remove as well.

Do I just change the permissions on directory y to 777 to resolve this issue without causing any other issues?

You could do that, but before you do, make sure you discuss this with the WD support.

Keep in mind, the use of SSH could very easily invalidate your warranty, since it is not supported.

Use of SSH up to the point of querying the device could still be ok, but making any type of changes will immediately invalidate your warranty.

John1000 wrote:

 

Above shows some detail of the issue that I am having.  I can not remove directory  x or subdirectory y.

 

You can’t delete X because it contains Y.

And Y cannot be deleted because it’s set for READ ONLY.

That’s bizzare.  

Yes, changing it to 777 would fix that issue.

But I’m wondering how ownership of all that got set to root.root.

Should be (username).share.

TonyPh12345 wrote:

 

But I’m wondering how ownership of all that got set to root.root.

 

Should be (username).share.

I believe that’s also part of the bug that I mentioned above with moving files to the USB.  It’s been a while since I’ve done that so I can’t really remember everything that it changed when I did it last. 

Also, I know that it will do the same thing if it writes a file from Android (at least from XBMC in Android) to the USB drive, at the least over NFS.  But it doesn’t do it from a Windows PC over SMB, so I’m not sure what’s going on with that.

@John1000,

First cd to x, then

chmod -R 777 y                 although you should have been able to do

chmod -R 777 x                 and I believe that should have changed “y” permissions also.

Then you should be able to delete “y”

rm -R y

You’ll probably want to change the grp and own

chgrp -R share x

chown -R nobody x

As for why it is doing this, I don’t know but it maybe due to the fact that you can’t set the USB share permissions like you do for the rest of the shares.  Perhaps it’s defaulting to a set of defined permissions.

Thanks to all who replied.   I should have enough input to proceed from here.  Thanks again.

Just as an added note, I started another job to transfer files from a USB device to the NAS last night.  The transfer size was approx. 1.2 GB.  I started it last night and it was still in process this evening almost 24 hours later.  Now it is about 3 hours later, and I am getting the same internal server error when trying to login that I got after scheduling the last job that created the files that could not be deleted.  Looks like another reboot will be required with unknown results - probably not in my favor.

So my short history so far with this NAS has been that NOUSB-NAS job that has attempted to transfer a “significant” amount of data has succeeded, has taken an inordinate amount of time, and has required a reboot of the NAS.  I have done many smaller transfers successfully, but larger transfer apparently fail (100% of the time for, me at least).

This is very frustrating for me.  I am aware that large transfers often do fail on any computer (HD to HD, HD to USB, USB to HD, etc).  I would normally not attempt to transfer large amounts of data at one time but would rather break the job up into smaller chunks.   But given that the current implementation of the software on this NAS does not allow selection of multiple folders on the source, I have been stuck with trying to transfer larger amounts of data at one time.

From day one, I was disappointed at some of the glaring missing functionality of this device.  It’s too bad since it seems to come close to offering what I need but lacks some of the very basic functionality that would at least give me a way to work around some of the issues I have encountered.  It seems obvious to me that transferring large amounts of data to the NAS is problematic.  I might be able to deal with that if there was a way to schedule jobs to transfer the data in smaller chunks which has worked so far for me.  But alas, that functionality is missing.

Count me as a very weary consumer who is looking for a workable NAS solution - something that just works.  Seagate put me through the wringer with their  “Business Storage” NAS, and now I am spending way too much time trying to just get my data onto to this NAS let alone verify that I can get may data safely off the device when there is a failure of some sort.

Tinwarble wrote:

Also, I know that it will do the same thing if it writes a file from Android (at least from XBMC in Android) to the USB drive, at the least over NFS.

That’s quite possible with NFS, because with NFS, the CLIENT is in control of ownership and permissions, not the server.  With SMB, it’s the opposite; the server is in complete control.

TonyPh12345 wrote:


Tinwarble wrote:

Also, I know that it will do the same thing if it writes a file from Android (at least from XBMC in Android) to the USB drive, at the least over NFS.


That’s quite possible with NFS, because with NFS, the CLIENT is in control of ownership and permissions, not the server.  With SMB, it’s the opposite; the server is in complete control.

Agreed, but it only happens (for me) when writing to the USB, not to the NAS. :wink:

I would expect permissions to be same whether writing to the NAS or the USB.

AAhhhh.   Ok, now I’m seeing the light.

The USB is probably NTFS, not EXT3/4, so there are no descrete file permissions or ownership.

That’s controlled by the options the EX4 is using when it mounts the USB drive to the file system.  :)

I’d have to plug in a USB drive and see what the mount table looks like.