Hello,

I've recently upgrade my unraid from 4.7 to 5.0.

It's because I have to add some HDD, and currently the 3TB are cheaper than 2TB...

So the NAS with 20 disks upgrade nicely from 4.7 to 5.0, then I've just changed the parity disk from 2TB to 3TB until now.

 

However, I've recently discovered something strange, on some directories inside a share, I cannot delete or rename some files.

I've not run a lot of investigation, but I can copy a file into those directories, but I cannot delete this file, or rename it (message = Error : please remove the write protection)

On the level just above, no problem. On another directory, no problem at all.

 

f.e. The share is Tower/Video, I can copy a file into directory Video/Films/Web, but there is no way to delete or rename it from windows (no problem with putty and mc).

I can also copy the same file into Video/Films or Video/Films/HD-New and in those directories I can delete or rename the file without problem.

Of course the shares user access remain constant, it's inside the share itself.

Strangely, I can create a directory inside, f.e. Video/Films/Web/Test and there I can copy files, delete and rename, and even delete the directory Test.

But it's different for the files.

 

I've never meet this issue when I was on 4.7.

 

Syslog attached (v5.0.5)

syslog-2014-03-26.txt

Did you run the script to reset permissions to the new security model after doing the upgrade?

If it's the script called "New Permissions" in the "Upgrade Utilities", yes.

Do you know if it's a good idea to re-launch this script just to be sure?

Normally it's a one-time action only....

If it's the script called "New Permissions" in the "Upgrade Utilities", yes.

Do you know if it's a good idea to re-launch this script just to be sure?

Normally it's a one-time action only....

Yes - it is that script.  In principle it should be a one time action.

 

The script can also be run from a console/telnet session as the 'newperms' command.  If run with no parameters it is directly equivalent to the web version.  It can also take parameters to provide a specific path at which it should start.

 

Problems can arise if you have plugins that create files directly on the array with the wrong permissions.  You can use the newperms script to correct this although the correct fix in such a case would be to get them created with correct permissions in the first place.

How about the extended attributes fix?

I can't exactly tell from your description if this clearly applies, but your symptoms sound similar.

http://lime-technology.com/forum/index.php?topic=28484.0

 

Thanks for replies

 

How about the extended attributes fix?

I can't exactly tell from your description if this clearly applies, but your symptoms sound similar.

http://lime-technology.com/forum/index.php?topic=28484.0

 

It seems that those issues are related to the 'mover'. What is this?

 

There is no cache disk in my config, and there is my "go" file :

 

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

/boot/packages/cache_dirs -w -e "Work" -e "User"

/boot/unmenu/uu

 

As you can see, not too much.

 

Any clue?

May I use the 'New Permissions" script again with no jeopardy situation?

 

May I use the 'New Permissions" script again with no jeopardy situation?

It won't hurt anything. It is just going through your folders/files and doing chmod and chown on them.

 

Been a while since I used it. I think it launches a new window that you have to keep open until it finishes.

May I use the 'New Permissions" script again with no jeopardy situation?

It won't hurt anything. It is just going through your folders/files and doing chmod and chown on them.

 

Been a while since I used it. I think it launches a new window that you have to keep open until it finishes.

 

Thanks for some lights

 

Re-Done. I've run the script called "New Permissions" in the "Upgrade Utilities".

In fact something change. It seems that the solution is to find in this direction.

Some directories in which there was no possibilities to delete/rename a file seems to have a standard behaviour now. No problem to rename/delete a file after creation.

But in other directories, the problem doesn't change, still the "Error-write protection".

 

In fact there is something stange when using the script "New Permissions", it seems that this script does something on some disks only.

Here is the "command line" from the windows open by the script :

/usr/local/sbin/newperms

processing /mnt/disk1... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk1... chown -R nobody:users /mnt/disk1...sync

processing /mnt/disk10... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk10... chown -R nobody:users /mnt/disk10... sync

processing /mnt/disk11... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk11... chown -R nobody:users /mnt/disk11... sync

processing /mnt/disk12... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk12

 

But nothing about the disks 2-9 and 13-19..?

 

Does somebody know if this behaviour is correct, if it's possible to run the modification manually or something, and if it's the solution why doesn't the script work correctly inside all the server?

 

 

Did you let it finish? I don't have enough disks to make it go to "double digits". Maybe it is doing them in "alphanumeric" order, so it would be disk1, disk10, disk11, disk12, ..., disk18, disk19, disk2, disk3,  ..., disk8, disk9

Did you let it finish? I don't have enough disks to make it go to "double digits". Maybe it is doing them in "alphanumeric" order, so it would be disk1, disk10, disk11, disk12, ..., disk18, disk19, disk2, disk3,  ..., disk8, disk9

 

Yes of course. At the bottom of the window, there is a button "Close" that came at the end of the job.

In the beginning I had the same thought as you. But now?

 

 

Is it possible to have some clue about the script "New Permissions" that seems to be the root of the problem?

Thanks

 

It is just a bash script at /usr/local/sbin/newperms. I'm no bash programmer but it looks pretty simple. Don't really see how it could go wrong.

 

Looks like it's also supposed to print "completed" and the elapsed time when it is finished.

 

Maybe try it from the command line.

 

If you run the command 'newperms' form a console/telnet session then you will see it working through each disk in turn.    I prefer doing it that way to doing it via the web GUI.

Maybe try it from the command line.

 

If you run the command 'newperms' form a console/telnet session then you will see it working through each disk in turn.    I prefer doing it that way to doing it via the web GUI.

 

Done by the command line successfully (elapsed time 03:59:39).

Now the problems seems to be cleared.

 

For some reason, with the web GUI, the process is systematically stopped after a while at the 4th disk.

 

Nevertheless, thanks for the help,...

 

For some reason, with the web GUI, the process is systematically stopped after a while at the 4th disk.

Which GUI? The standard one, or an add-on?

The standard one -> "Utils", "Upgrade Utilities", "New Permissions".

Huh...I wonder if that's a reported bug in the std GUI?