Cannot access shares - permissions?

[scotttiamit]

Hi guys, I have a small server running unRAID 5.0RC3 which I had to rebuild the hardware but now the server is up and going and raid set valid with parity check complete. I have added a user with the same username and password and my share is set in SMB as export:yes and with security:public. In the SMB settings Enable SMB:Yes(workgroup) and Local Master:No.

 

Now when I browse to the UNRAID server from My Computer \\tower I can see the shares but when I try to access it I get an error 'You do not have permissions...' this is from my Windows 7 machine which is part of a domain. I tried to access from a Windowx XP maxhine on the same network which is not part of the domain and I get the same error.

 

If I have to use a username and password to access then that is OK but would prefer public access to all on the betwork but for some reason I am having no luck.

 

I have restarted the server tons of times, stoped and started the array and rebooted my machines/routers etc too.

 

I have a pro version at home also running the same version and have the same issue but it accepted my username/password when I mapped a drive and specified a different username/password that matched what I had set in unraid however no matter what I specify it seems to fail.

 

Am I missing something? Thanks in advance.

 

(log file attached)

 

Scott.

log.txt

[limetech]

Was this server previously running 4.7?  If so, you need to click 'New Permissions' utility on the Utility menu.

[opentoe]

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

[scotttiamit]

Yes was from 4.7.

 

Awesome guys thats for the replies I try that now and fingers crossed. I did notice though that one of the shares works OK but the others don't so must just need permissions set again. Will let you know if this doesn't sort it. I appreciate the quick response.

[chuck23322]

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

 

I also am having the problem of having to run new permissions more than once.  To get the right ownership for "new" files placed.  There have been other reports of this as well.

 

Also was an upgrade from 4.7, now on 5.0-RC3

 

I had a script like yours that I had to run.  I've been experimenting with something otherwise....  but neither seem to be an actual fix, but hacks.

 

http://lime-technology.com/forum/index.php?topic=19984.msg177893#msg177893

http://lime-technology.com/forum/index.php?topic=19984.msg180638#msg180638

 

Check a file that you are having problems with -- when you create a new file -- is it "root/root" ownership -- even if you created it with a non-root user?

[limetech]

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

 

I also am having the problem of having to run new permissions more than once.  To get the right ownership for "new" files placed.  There have been other reports of this as well.

 

Also was an upgrade from 4.7, now on 5.0-RC3

 

I had a script like yours that I had to run.  I've been experimenting with something otherwise....  but neither seem to be an actual fix, but hacks.

 

http://lime-technology.com/forum/index.php?topic=19984.msg177893#msg177893

http://lime-technology.com/forum/index.php?topic=19984.msg180638#msg180638

 

Check a file that you are having problems with -- when you create a new file -- is it "root/root" ownership -- even if you created it with a non-root user?

 

I looked over that thread... How are the files being created?  via some other computer on network?

[chuck23322]

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

 

I also am having the problem of having to run new permissions more than once.  To get the right ownership for "new" files placed.  There have been other reports of this as well.

 

Also was an upgrade from 4.7, now on 5.0-RC3

 

I had a script like yours that I had to run.  I've been experimenting with something otherwise....  but neither seem to be an actual fix, but hacks.

 

http://lime-technology.com/forum/index.php?topic=19984.msg177893#msg177893

http://lime-technology.com/forum/index.php?topic=19984.msg180638#msg180638

 

Check a file that you are having problems with -- when you create a new file -- is it "root/root" ownership -- even if you created it with a non-root user?

 

I looked over that thread... How are the files being created?  via some other computer on network?

 

In my case, the files are being created by a Windows 7 Laptop using a user account other than root -- we'll call it "usertest".

 

Share is mounted as a drive letter --- from command line -- net use p:\\unraid\DVDs /user:usertest

 

Software of varying kind (any kind) -- even simple drag/drop using explorer on to P:

 

Ownership on P: of the *NEW* files is root:root

 

Go to another machine, another Windows 7 machine,  having the same mounting of P, and same user.

 

Cannot access the files.  Can see the directory, but can't go "in it".

 

Re-run permissions, all is fine.

 

*Updated:  Had "UserTest" as an example -- learned earlier (another thread when I was first converting to 5.0) that you can't use capitals in usernames -- so all my users are lower case.

[Simon]

In my case, I create files from a Windows 7 machine just using a UNC (\\tower\<sharename>) path with no specific credentials (security is set to public in Unraid for that Share).

My (Dune) media player then attempts to read the file connecting as a named Read-only SMB user.  This file access fails. 

Telnetting in to Unraid I see the owner group of the file is root / root. Running

chown nobody:users

on the file allows access as normal.

 

 

[chuck23322]

In my case, I create files from a Windows 7 machine just using a UNC (\\tower\<sharename>) path with no specific credentials (security is set to public in Unraid for that Share).

My (Dune) media player then attempts to read the file connecting as a named Read-only SMB user.  This file access fails. 

Telnetting in to Unraid I see the owner group of the file is root / root. Running

chown nobody:users

on the file allows access as normal.

 

Have you run the "permissions script" fully at least one time?    Just trying to make sure we're all talking about creating files *after* running the "New Permissions" script (in the utilities menu) for the first time.  It's supposed to only require doing it once.

 

 

Also, is your build an upgrade from a 4.7 or 4.x system?

[Simon]

Have you run the "permissions script" fully at least one time?    Just trying to make sure we're all talking about creating files *after* running the "New Permissions" script (in the utilities menu) for the first time.  It's supposed to only require doing it once.

Yup - ran it once when I first went from 4.7 to 5.0-rc3.  My post applies specifically to files added post-upgrade.  Unless something is really weird with my set-up, I imagine anyone running 5.0-rc3 who connects unauthenticated to Unraid via Windows and creates a file will find the owner:group is root:root.

[chuck23322]

Have you run the "permissions script" fully at least one time?    Just trying to make sure we're all talking about creating files *after* running the "New Permissions" script (in the utilities menu) for the first time.  It's supposed to only require doing it once.

Yup - ran it once when I first went from 4.7 to 5.0-rc3.  My post applies specifically to files added post-upgrade.  Unless something is really weird with my set-up, I imagine anyone running 5.0-rc3 who connects unauthenticated to Unraid via Windows and creates a file will find the owner:group is root:root.

 

Ok, that's running consistant with others who have this problem.

 

1) All reports have been from 4.7 -> 5.0-xx upgrades

 

2) Permissions script has been run at least once

 

3) New files are set to "root:root" and are not accessible by other machines

 

4) Re-running permissions script fixes the problem, until new files are created.  Also a change owner (same thing that the script does) to nobody:users also fixes it, again until a new file is created.

 

5) It's only "new" files that can't be accessed

 

6) Not sure about the unauthenticated part -- I'm definitely {well, I think I am!} - using an authenticated user.

 

 

I think that's what we know right now.

[limetech]

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

 

I also am having the problem of having to run new permissions more than once.  To get the right ownership for "new" files placed.  There have been other reports of this as well.

 

Also was an upgrade from 4.7, now on 5.0-RC3

 

I had a script like yours that I had to run.  I've been experimenting with something otherwise....  but neither seem to be an actual fix, but hacks.

 

http://lime-technology.com/forum/index.php?topic=19984.msg177893#msg177893

http://lime-technology.com/forum/index.php?topic=19984.msg180638#msg180638

 

Check a file that you are having problems with -- when you create a new file -- is it "root/root" ownership -- even if you created it with a non-root user?

 

I looked over that thread... How are the files being created?  via some other computer on network?

 

In my case, the files are being created by a Windows 7 Laptop using a user account other than root -- we'll call it "usertest".

 

Share is mounted as a drive letter --- from command line -- net use p:\\unraid\DVDs /user:usertest

 

Software of varying kind (any kind) -- even simple drag/drop using explorer on to P:

 

Ownership on P: of the *NEW* files is root:root

 

Go to another machine, another Windows 7 machine,  having the same mounting of P, and same user.

 

Cannot access the files.  Can see the directory, but can't go "in it".

 

Re-run permissions, all is fine.

 

*Updated:  Had "UserTest" as an example -- learned earlier (another thread when I was first converting to 5.0) that you can't use capitals in usernames -- so all my users are lower case.

 

I tried this using both command line version of mapping a driver letter (as you did above), as well as through Explorer's "map network drive" UI, with same results: works perfectly.

 

Do you have any add-ons running that could possibly be modifying the unraid-side samba configuration files, or do you have a file in the config directory on the flash called 'smb-extra.conf'?  If no to both, then please open a telnet session to the server and type type this command:

 

testparm -sv >/boot/samba.txt

 

Then find the file "samba.txt" on your flash and post here.

[Simon]

Here's mine:

 

Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Can't find include file /boot/config/smb-extra.conf
Processing section "[flash]"
Processing section "[Kids]"
Processing section "[Movies]"
Processing section "[Photos]"
Processing section "[stdDef]"
Processing section "[TVShows]"
Processing section "[Temp]"
Loaded services file OK.
Server role: ROLE_STANDALONE

 

I have the cache_dirs plugin running.

[limetech]

Here's mine:

 

Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Can't find include file /boot/config/smb-extra.conf
Processing section "[flash]"
Processing section "[Kids]"
Processing section "[Movies]"
Processing section "[Photos]"
Processing section "[stdDef]"
Processing section "[TVShows]"
Processing section "[Temp]"
Loaded services file OK.
Server role: ROLE_STANDALONE

 

I have the cache_dirs plugin running.

 

You forgot the "-sv" switch.

[Simon]

 

Edit: I've only tried writing to [Movies] and [TVShows] since I upgraded and they both have the problem

samba.txt

[limetech]

 

Edit: I've only tried writing to [Movies] and [TVShows] since I upgraded and they both have the problem

 

Ok here's something I've found.  If, on the windows side, you authenticate with the server as user 'root', then this will cause problems, ie, files created will have owner 'root' in group 'root'.  In thinking about it, there is a bug in 5.0: the 'root' user should not show up in the "User Access" list for Secure and Private security modes.  Combined with windows credential caching, this might explain this issue.  I need to work on this a little more, but I think we're on to something.  Do you think it's possible that sometime in the past, you used user "root" to connect to the server?

[Simon]

 

Edit: I've only tried writing to [Movies] and [TVShows] since I upgraded and they both have the problem

 

Ok here's something I've found.  If, on the windows side, you authenticate with the server as user 'root', then this will cause problems, ie, files created will have owner 'root' in group 'root'.  In thinking about it, there is a bug in 5.0: the 'root' user should not show up in the "User Access" list for Secure and Private security modes.  Combined with windows credential caching, this might explain this issue.  I need to work on this a little more, but I think we're on to something.  Do you think it's possible that sometime in the past, you used user "root" to connect to the server?

 

I almost certainly have connected as Root in the past (when I was running 4.7) but haven't for a few months.  I did think along the same lines, but doing a

net use

showed no connections on the Windows 7 machine (my assumption was that if I was still connected as root somehow, it would show up there).

 

I rebuilt a machine a couple of weeks ago that has never connected to the Unraid server, when I get home tonight I'll try connecting via that to see if I get the same behavior.

[chuck23322]

 

Edit: I've only tried writing to [Movies] and [TVShows] since I upgraded and they both have the problem

 

Ok here's something I've found.  If, on the windows side, you authenticate with the server as user 'root', then this will cause problems, ie, files created will have owner 'root' in group 'root'.  In thinking about it, there is a bug in 5.0: the 'root' user should not show up in the "User Access" list for Secure and Private security modes.  Combined with windows credential caching, this might explain this issue.  I need to work on this a little more, but I think we're on to something.  Do you think it's possible that sometime in the past, you used user "root" to connect to the server?

 

I am certain that I've used root in the past.  Both in 4.7 and 5.x days.  Once investigating this problem,  I gave up on being lazy at times (using root) and sticking to only using /user:username

 

{Update:  I'm at work right now, but later tonight I'll get the samba.txt file requested}

[chuck23322]

 

I am certain that I've used root in the past.  Both in 4.7 and 5.x days.  Once investigating this problem,  I gave up on being lazy at times (using root) and sticking to only using /user:username

 

{Update:  I'm at work right now, but later tonight I'll get the samba.txt file requested}

 

Ok, I did some extensive (I think) testing today -- on 5.0-RC3 -- steps involved

 

1) Used two machines, both Windows7

2) Started with a share that is set to "public" security

3) Two user accounts "chuck" and "any"

4) Did a "net use x: /d" to remove all connections, from both machines

 

PC1 - net use u: \\unraid\chuck /user:chuck

 

u:

mkdir test3

echo abcde > test3\testfile

 

 

PC1 - net use u: \\unraid\chuck /user:any

 

u:

mkdir test4

echo abcde > test4\testfile

 

Results:  Files created as "chuck:users" and "any:users" --- but both "chuck" and "any" could access the file created by the other

 

root@unraid:/mnt/user/Chuck# ls -l | grep test3
drwxrwx--- 1 chuck  users        48 May 26 11:25 test3/
root@unraid:/mnt/user/Chuck#
root@unraid:/mnt/user/Chuck# cd test3
root@unraid:/mnt/user/Chuck/test3#
root@unraid:/mnt/user/Chuck/test3# ls -l | grep testfile
-rw-rw---- 1 chuck users 8 May 26 11:25 testfile
root@unraid:/mnt/user/Chuck/test3#
root@unraid:/mnt/user/Chuck/test3#
root@unraid:/mnt/user/Chuck/test3# cd ..
root@unraid:/mnt/user/Chuck#
root@unraid:/mnt/user/Chuck# ls -l | grep test4
drwxrwx--- 1 any    users        72 May 26 11:28 test4/
root@unraid:/mnt/user/Chuck#
root@unraid:/mnt/user/Chuck# cd test4
root@unraid:/mnt/user/Chuck/test4#
root@unraid:/mnt/user/Chuck/test4# ls -l | grep test4
root@unraid:/mnt/user/Chuck/test4# ls -l | grep testfile
-rw-rw---- 1 any users 9 May 26 11:28 testfile
root@unraid:/mnt/user/Chuck/test4#

 

5) Removed connections -- "net use u: /d"

6) Changed share to be "private" security -- gave both "chuck" and "any" read/write access

7) Repeated test

 

Same results.  Directory and file were created as "chuck:users" and "any:users" -- but both Chuck and any could access files created by the other account

 

8} Removed connections -- "net use u: /d"

9) Mounted share on PC1 as "root" -- "net use u: /user:root"

10) Repeated test -- created test7 directory and testfile under that directory

 

File and directory ownerships as "root:root"

root@unraid:/mnt/user/Chuck# ls -l | grep test7
drwxrwx--- 1 root   root         72 May 26 11:32 test7/
root@unraid:/mnt/user/Chuck# cd test7
root@unraid:/mnt/user/Chuck/test7# ls -l | grep test
-rw-rw---- 1 root root 9 May 26 11:32 testfile
root@unraid:/mnt/user/Chuck/test7#

 

11) Other PC2 (as "any") could see the test7 directory, could not CD to it, nor access the testfile inside of test7

 

---

 

Summary:

 

1) It seems that if I mount a drive, specifically as a "user" account (aka, in my case "chuck" and/or "any") -- that the file is created with the "owner" as the account that created the file, and the group as "users"

2) If #1, then both "chuck" and "any" can access the file

 

3) If I mount a drive as "root" -- files are created as "root:root"

4) If #3, then no "user" account can access the file until the permissions script is run (or manually changing the owner to "nobody:users")

 

 

[limetech]

Ok, I did some extensive (I think) testing today -- on 5.0-RC3 -- steps involved

 

...

 

I get the same result.  Everything is fine unless you use 'root' - this is a bug and fixed in next release.  The fix is to prevent authentication using the 'root' user.  The 'root' user should not appear in any Host/Access list.

[chuck23322]

Ok, I did some extensive (I think) testing today -- on 5.0-RC3 -- steps involved

 

...

 

I get the same result.  Everything is fine unless you use 'root' - this is a bug and fixed in next release.  The fix is to prevent authentication using the 'root' user.  The 'root' user should not appear in any Host/Access list.

 

So, just for my education -- when the permissions script runs -- it sets everything to nobody:users

 

But when files are created with user (non-root) accounts,  it creates those files as --  nameofuser:users

 

And that's normal and OK and proper behavior...  do I have it right?

[limetech]

Ok, I did some extensive (I think) testing today -- on 5.0-RC3 -- steps involved

 

...

 

I get the same result.  Everything is fine unless you use 'root' - this is a bug and fixed in next release.  The fix is to prevent authentication using the 'root' user.  The 'root' user should not appear in any Host/Access list.

 

So, just for my education -- when the permissions script runs -- it sets everything to nobody:users

 

But when files are created with user (non-root) accounts,  it creates those files as --  nameofuser:users

 

And that's normal and OK and proper behavior...  do I have it right?

 

Yes that is right.  The file 'owner' in unRaid security model set up is inconsequential; there's really no concept of "file ownership", there's just the concept of who is allowed access (and what kind of access) to the set of files within a share.  [Note: this is not necessarily true when Active Directory is being used - in this case all file access is under control of AD model.]

[opentoe]

Ok, I did some extensive (I think) testing today -- on 5.0-RC3 -- steps involved

 

...

 

I get the same result.  Everything is fine unless you use 'root' - this is a bug and fixed in next release.  The fix is to prevent authentication using the 'root' user.  The 'root' user should not appear in any Host/Access list.

 

This could solve lots of my issues. All my file/folders that are created on my unraid server are from the Sickbeard program. Now, what credentials is that program using? I sign into that computer (where sickbeard is running) not using ROOT but a regular user name I have set up there.

 

 

 

 

[global]

        workgroup = SOL

        server string = storage array

        map to guest = Bad User

        null passwords = Yes

        passdb backend = smbpasswd

        syslog = 0

        syslog only = Yes

        max protocol = SMB2

        unix extensions = No

        load printers = No

        printcap name = /dev/null

        disable spoolss = Yes

        show add printer wizard = No

        local master = No

        idmap config * : backend = tdb

        create mask = 0770

        directory mask = 0770

        use sendfile = Yes

        map archive = No

        wide links = Yes

 

 

        comment = Flash share

        path = /boot

        read only = No

        create mask = 0777

        directory mask = 0777

        guest ok = Yes

 

        path = /mnt/user/email

        read only = No

        guest ok = Yes

 

[movies]

        path = /mnt/user/movies

        read only = No

        guest ok = Yes

 

[mp3]

        path = /mnt/user/mp3

        read only = No

        guest ok = Yes

 

[my documents]

        path = /mnt/user/my documents

        read only = No

        guest ok = Yes

 

[my pictures]

        path = /mnt/user/my pictures

        read only = No

        guest ok = Yes

 

 

[software]

        path = /mnt/user/software

        read only = No

        guest ok = Yes

 

[unraid]

        comment = Main Unraid Share

        path = /mnt/user/unraid

        read only = No

        guest ok = Yes

 

[Kosta]

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.

[opentoe]

Above it says MAP TO GUEST = BAD USER. Is that wrong?

 

I created one user under the unraid web GUI. Since I'm having such weird and odd permission issues I deleted the user and of course only root is there. A quick reboot of all my computers and just did a quick test with Sickbeard and it actually worked the way it should have. It post processed ok and was able to delete files it created. I'll have to keep an eye on it, because I did have to re-run the file permissions utility again. I couldn't delete some folders again that were previously created by Sickbeard, but was able to delete them using Midnight commander locally using root. So right now it seems all my issues are related to file/folder permissions. Is there a umask set?