scotttiamit Posted May 24, 2012 Share Posted May 24, 2012 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 Quote Link to comment
limetech Posted May 25, 2012 Share Posted May 25, 2012 Was this server previously running 4.7? If so, you need to click 'New Permissions' utility on the Utility menu. Quote Link to comment
opentoe Posted May 25, 2012 Share Posted May 25, 2012 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 1 Quote Link to comment
scotttiamit Posted May 25, 2012 Author Share Posted May 25, 2012 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. Quote Link to comment
chuck23322 Posted May 25, 2012 Share Posted May 25, 2012 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? Quote Link to comment
limetech Posted May 25, 2012 Share Posted May 25, 2012 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? Quote Link to comment
chuck23322 Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
Simon Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
chuck23322 Posted May 25, 2012 Share Posted May 25, 2012 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? Quote Link to comment
Simon Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
chuck23322 Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
limetech Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
Simon Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
limetech Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
Simon Posted May 25, 2012 Share Posted May 25, 2012 Edit: I've only tried writing to [Movies] and [TVShows] since I upgraded and they both have the problem samba.txt Quote Link to comment
limetech Posted May 25, 2012 Share Posted May 25, 2012 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? Quote Link to comment
Simon Posted May 25, 2012 Share Posted May 25, 2012 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. Quote Link to comment
chuck23322 Posted May 25, 2012 Share Posted May 25, 2012 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} Quote Link to comment
chuck23322 Posted May 26, 2012 Share Posted May 26, 2012 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") Quote Link to comment
limetech Posted May 26, 2012 Share Posted May 26, 2012 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. Quote Link to comment
chuck23322 Posted May 26, 2012 Share Posted May 26, 2012 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? Quote Link to comment
limetech Posted May 26, 2012 Share Posted May 26, 2012 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.] Quote Link to comment
opentoe Posted May 26, 2012 Share Posted May 26, 2012 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 Quote Link to comment
Kosta Posted May 26, 2012 Share Posted May 26, 2012 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. Quote Link to comment
opentoe Posted May 26, 2012 Share Posted May 26, 2012 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? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.