[SOLVED] Permissions Issue - Unable to Delete Files

[nickro8303]

Hi

 

Currently running v6b10a. I have a large amount of data that I recently transferred from an internal hard drive into the array. At first I wasn't able to open any of the files but I was able to fix that by running the new permissions tool. I've been trying to delete some of those files and folders but I keep getting the permissions error message. I tired running the new permissions tool again but that doesn't work. I also see that I have full access on the root folder but not on any of the sub folders.

syslog.txt

[itimpi]

I did not notice anything obvious regarding your delete issue, but I did notice that you are installing what looks like the 32-bit versions of the utempter and screen packages.  For v6 you should be using 64-bit versions.  Not sure if doing this can have knock on effects.

[nickro8303]

I installed screen from the unMENU Pkg Manager tab and it says it's for both x86 and x64bit versions. I don't remember installing utempter though unless it come pre-installed somewhere I didn't add it manually. Any ideas on what I can do to change the permissions on that folder?

[itimpi]

I installed screen from the unMENU Pkg Manager tab and it says it's for both x86 and x64bit versions. I don't remember installing utempter though unless it come pre-installed somewhere I didn't add it manually.

Interesting - if you go to the slackware packages site it gives different package names for the 32-bit and 64-bit versions of unRAID.  I had grabbed mine from there and as it is standard slackware package am installing it by simply putting it into the 'extra' folder on the flash.  The utempter package is also required as screen has a dependency on that.

Any ideas on what I can do to change the permissions on that folder?

It is difficult to guess what your problem might be.

 

I would suggest that you post the output of a command of the form

ls -l /mnt/user/sharename/path

run from a console/telnet session.  That would allow use to see the underlying Unix permissions.  Also a screen shot of the GUI page for the relevant share settings might be useful.

[nickro8303]

Ok I added the output of the command. I also added screen shots of the share settings and the screen package I installed from package manager in unMENU. I see that utempter was installed along with screen.

folder_permissions.txt

[itimpi]

According to the syslog, the screen and utempter packages being installed are not the versions shown in your screenshot.  The screenshots show the 64-bit versions while the syslog seems to show the 32-bit versions.  You might want to check what is present under /boot/packages.

 

Nothing obvious in the 'ls' output that might cause issues.

 

The screenshot for the share settings seems to be the wrong one

[nickro8303]

My bad. I got the right one this time. I also added a screen shot of the package folder on the flash.

 

[itimpi]

The screenshot of the packages folder shows that you have both the 32-bit (the files with i486 in their name) and the 64-bit ones.  I would think that the 32-bit ones should not be present.

 

The share settings look fine.  Cannot see any reason why you are having issues.

 

You could as a workaround try removing them from the linux level in a console/telnet session to see if that works, and if not you might more error information.

[nickro8303]

I see the 32bit rar files but they don't seem to have been unzipped into that folder. Doesn't that mean they aren't installed? When you say

You could as a workaround try removing them from the linux level in a console/telnet session to see if that works, and if not you might more error information.

 

could you be a little more specific? I'm not that well versed in Linux. One semester at ITT Tech about 4 years ago but haven't used it much since then.

[nickro8303]

It's strange I have full access to the root folder and can delete files from there  without a problem but if I try to delete any thing with sub-folders or the sub-folders themselves I get a permissions error message. When I look at the NTFS permissions on those sub-folders it says no users have any permissions on those folders.

 

[itimpi]

It's strange I have full access to the root folder and can delete files from there  without a problem but if I try to delete any thing with sub-folders or the sub-folders themselves I get a permissions error message. When I look at the NTFS permissions on those sub-folders it says no users have any permissions on those folders.

On taking another look I notice that the folder permissions do not have the 'w bits set.    On my system they are all set on the folders.

 

It might be worth trying something like

newperms /mnt/user/Media/

and then see if the permissions shown by the 'ls' command used earlier have changed?

[nickro8303]

That seems to worked for two of the sub-folders but the rest stayed the same.

 

[itimpi]

That seems to worked for two of the sub-folders but the rest stayed the same.

Weird - I am not sure what governs this.  The one thing I note is that those folders where the 'w' bit was at all levels after doing newperms already had it at one level.

 

You could try setting the write bit explicitly picking a folder where you want to manipulate the contents and using a command like

chmod -R +w /mnt/user/Media/Imported/foldername 

and see if that resolves the issues for that folder.

 

Is there anything in your Samba or NFS settings that might be causing this to happen I wonder?

[nickro8303]

Well I'm not sure what to make of this, it says the file or directory cannot be found but I copied and pasted it directly from the share on the unRAID index.

 

[nickro8303]

Ok I got it. For some reason I have to add \ between spaces in folder names to get the command to run. After I did that it worked. I guess I'll just have to go through and manually change the permissions on each sub-folder in that folder. Thanks for your help.

[itimpi]

Ok I got it. For some reason I have to add \ between spaces in folder names to get the command to run.

The alternative is to put quotes around the name:.

After I did that it worked. I guess I'll just have to go through and manually change the permissions on each sub-folder in that folder. Thanks for your help.

The -R option means recurse into sub-folders.  You can start at the level you want to change, and anything under it is also changed.

 

An important issue is to try and identify why you would get this issue in the first place.  If that is not understood then it is likely to re-occur.

[nickro8303]

Ok thanks for that insight. Like I said I'm not much of linux guru.

 

This data was transferred from the internal hard drive that I was using prior to setting up my unRAID server. I followed the directions on the wiki http://lime-technology.com/wiki/index.php/Transferring_Files_Within_the_unRAID_Server.

[nickro8303]

Ok so I messed up somewhere and removed some persmissions to that share because now I cannot browse to it at all. Can you tell me where I went wrong? I copied the CLI commands I used to a txt file.

cli_file.txt

syslog.txt

[itimpi]

Not exactly sure which one went wrong - but somewhere along there you lost the read ('r') permission.  It could be aside-effect of not correctly escaping items with spaces in the names.

 

You could correct this by simply running the command

chmod -R +rw /mnt/user/Media

which will correct it for everything under the Media share making sure that all files/folders have read and write permissions for everyone.  Note that the options are case sensitive so that -R means recurse, while -r (if you accidentally used it) would mean remove the read permission. 

[nickro8303]

Ok got it. I think I'm going to have to do some refreshing on my linux usage. I seem to be doing more harm than good. Thanks again for all your help.