I also have a permissions problem but I'm not sure if this is supposed to be expected behaviour or not. The problem becomes apparent when samba shares that are exposed via "Secure" security option. Let's assume I have a folder mounted as follows:

 

//192.168.1.10/Downloads           /mnt/tower/Downloads       cifs username=downloads,password=downloads,_netdev 0 0

 

If I create a folder in that mounted folder, it gets created with the following permissions:

 

drwxrwx--- 1 downloads users   48 2012-05-26 22:55 test/

 

Now even though the "users" group has the execute permission, if I try accessing that folder as a guest/anonymous user, I get an access denied error. What is peculiar is that this only happens with folders. Files that are created in the same fashion can be accessed by guest/anonymous users. This discrepancy leads me to believe that this is probably not intended behaviour. I have attempted setting the uid/gid to nobody/users in fstab as well, but the setting is ignored by unraid - the owner always ends up being the user that was used for mounting the share.

 

Please let me know if I can provide any additional details.

 

All mine are setup as PUBLIC and I still have the issue. Could be just a little bug with how unraid creates files/folders and how their permissions are setup. At least I've been able to boil down ALL my current issues to a permissions scenario.

Apparently it's not just root that is affected, nor is it only affecting those who have upgraded from 4.7.  I did a fresh install of 5.0rc3 and created a bunch of public shares and 1 private share.  I created a user "jon" to access the private share.  When I authenticated as "jon" from a Win7 machine to access the private share, I could no longer create files in the public share without the ownership being set to "jon".  This makes those files inaccessible without authenticating as "jon", even though they are in a public folder.

 

Is this a bug or a feature? 

Apparently it's not just root that is affected, nor is it only affecting those who have upgraded from 4.7.  I did a fresh install of 5.0rc3 and created a bunch of public shares and 1 private share.  I created a user "jon" to access the private share.  When I authenticated as "jon" from a Win7 machine to access the private share, I could no longer create files in the public share without the ownership being set to "jon".  This makes those files inaccessible without authenticating as "jon", even though they are in a public folder.

 

Is this a bug or a feature? 

 

As an experiment, on your win7 PC open a command window and type this:

net use * /delete

 

And then see if the same behavior exists.

As an experiment, on your win7 PC open a command window and type this:

net use * /delete

 

And then see if the same behavior exists.

Same behavior exists - folder created with ownership "jon" after net use * /delete.

 

Double-checking my steps:

 

[*]Rebooted PC1 to be sure cached credentials are cleared

[*]Accessed public share \\tower\movies - no problems, no password prompts

[*]Accessed private share \\tower\jon - logged in as jon when prompted

[*]Accessed public share \\tower\movies and created folder "testjon"

[*]ran "net use * /delete" in cmd window, which disconnected \\tower\jon successfully

[*]Accessed public share \\tower\movies and created folder "testnetuse"

[*]On PC2 (not authenticated on tower), browsed to \\tower\movies

[*]Access Denied when trying to browse to "testjon" or "testnetuse"

[*]Ownership shows "jon" for both "testjon" and "testnetuse" folders. Other folders show "nobody" as owner.

I suspect that Win7 caches the credentials and just reapplies them when reconnecting to the share after the net use * /delete.  I've battled the same problem at work when trying to login as administrator to a network share that the user has already authenticated to.

As an experiment, on your win7 PC open a command window and type this:

net use * /delete

 

And then see if the same behavior exists.

Same behavior exists - folder created with ownership "jon" after net use * /delete.

 

Double-checking my steps:

 

[*]Rebooted PC1 to be sure cached credentials are cleared

[*]Accessed public share \\tower\movies - no problems, no password prompts

[*]Accessed private share \\tower\jon - logged in as jon when prompted

[*]Accessed public share \\tower\movies and created folder "testjon"

[*]ran "net use * /delete" in cmd window, which disconnected \\tower\jon successfully

[*]Accessed public share \\tower\movies and created folder "testnetuse"

[*]On PC2 (not authenticated on tower), browsed to \\tower\movies

[*]Access Denied when trying to browse to "testjon" or "testnetuse"

[*]Ownership shows "jon" for both "testjon" and "testnetuse" folders. Other folders show "nobody" as owner.

I suspect that Win7 caches the credentials and just reapplies them when reconnecting to the share after the net use * /delete.  I've battled the same problem at work when trying to login as administrator to a network share that the user has already authenticated to.

 

On PC2, if you do the 'net use * /delete' do you get same result (not being able to access public share from PC2)?

 

Are you using homegroups?

On PC2, if you do the 'net use * /delete' do you get same result (not being able to access public share from PC2)?

 

Are you using homegroups?

No, I am not using homegroups.

 

On PC2 I haven't authenticated to the private share since the last reboot, so when I run "net use * /delete" it prompts me to disconnect only from the public share \\tower\movies.  Doing so, then reconnecting to \\tower\movies does not change anything - I can still access folders that were created by "nobody" (no authentication) but I cannot access a folder that was created on the public share by "jon" on PC1.  In other words, PC1 and PC2 seeing the same problem.

 

I also tried rebooting PC2 to clear cached credentials. Before authenticating I can access folders in the public share that were created without authentication (nobody's files).  I cannot access jon's files.  Oddly, when I try to authenticate to \\tower\jon it will not accept my credentials for "jon" now, even after resetting my password just in case.  I may have screwed something up earlier when I deleted the "jon" user and ran the New Permissions script (that did fix the ownership issue for existing files).  When I first posted here I recreated the "jon" user. 

 

Sorry to bail, but I'm back to work tomorrow and am heading to bed.  I'll be back online tomorrow - will leave everything running in case you have any more troubleshooting steps for me to try.

 

Thanks for your help!  This is my second day with unraid and I am loving it so far!

Please refer to this post and see if it also solves this issue.

http://lime-technology.com/forum/index.php?topic=20443.msg181909#msg181909

 

OK, I made the change but upon stopping and starting the array it is stuck on "Mounting" the cache disk, and the array status is "Starting..." even after I click the refresh button (15 minutes and counting).  All array disks and parity look fine, but user shares are inaccessible.  Not sure if this is normal, but I did see several drives show "resizing" during the array start process.

 

Is it safe to reboot the server or is there a better way to gracefully restart via the web panel?  I don't have IPMIview or puTTY on this computer, and the only command I know to try is "shutdown -r now".  In general, is resetting the server or running the shutdown command safe when the array is started or starting?

Edit: Found commands for stopping the array at http://lime-technology.com/forum/index.php?topic=6255.0.  I still had to power off the server though as the shutdown -r -f now command did not work.

Confirmed that RC4 resolves this issue by no longer allowing root to access the shares remotely. My Windows 7 machine that was creating the problem due to cached credentials asked me to provide new ones once I upgraded to RC4. 

On 2012-05-25 at 3:30 AM, opentoe said:

I've setup a batch file to do this automatically, since I'm having to run it more then once.

 

chmod -R go-rwx,u-x,g+u,ug+X /mnt/disk1-whatever

chown -R nobody:users /mnt/disk1-whatever

Your advice helped me! Moved over folders from my Linux server to a USB disk. Switch to unRaid. Move the folders back to unRaid. Having problems with some folders/files that I could show but not change or write to. The folders was in the Share called Windows. Thanks again!

chmod -R go-rwx,u-x,g+u,ug+X /mnt/user/Windows
chown -R nobody:users /mnt/user/Windows

 

Edited August 20, 20178 yr by stormense