- new Fedora Core 4 box named "bar", Samba version 3.0.14a-2
- create user "foo", with home directory /home/foo
- set foo's Samba password with "smbpasswd -a" (security = user)
- from an XP SP2 box, try to see the list of shares on the Samba server with Start -> Run... -> \\bar<ENTER>
- we get an authentication popup and get authenticated correctly
- Works! We can see the list of shares on Samba server "bar", including the share named "foo", which is created by the special Samba [homes] share
- try to access the share named "foo" and get "the network path was not found"
- change /etc/passwd to set foo's home directory to /tmp/foo
- mkdir /tmp/foo, then set owner "foo", group "foo", permissions 755 (rwxr-xr-x)
- restart Samba with "service smb restart" (or "/etc/init.d/smb restart")
- try to access the share named "foo" and it works!
- we even tried creating a share named "blah" pointing to path "/home/blah", with owner, group, perms set for user "foo"
- this fails with "the network path was not found" as above for "/home/foo"
Things we've checked:
- confirmed IP & hostname set correctly in /etc/hosts
- confirmed that we're being authenticated correctly, by trying (and failing) to use an incorrect password for user "foo".
- confirmed that we can use the pre-defined [tmp] share for /tmp
- ran "getfacl /home" and "getfacl /home/foo" and saw nothing weird
- heck, we even ran "lsattr -a /home/foo" in case there was some bizarre attribute affecting us; got "-------------" for everything
So, just for grins, we decided to watch smbd experience the error. Used "strace -p PID" and found this when the XP client tried to access the share named "foo":
...
geteuid32() = 0
getegid32() = 0
setgroups32(1, [500]) = 0
setresgid32(-1, 500, -1) = 0
getegid32() = 500
setresuid32(500, 500, -1) = 0
geteuid32() = 500
stat64("/home/foo", 0xbf9167d4) = -1 EACCES (Permission denied)
...
Note that UID 500 is user "foo" and GID 500 is group "foo". It looks like the file system permissions are blocking us here somehow. What we don't understand is that we can "su - foo" and see everything in /home/foo.
Finally, the problem seems to exist only for certain paths (so far anything under /home and /root).
Thanks in advance to anyone who can shed light on this.
-klode
- create user "foo", with home directory /home/foo
- set foo's Samba password with "smbpasswd -a" (security = user)
- from an XP SP2 box, try to see the list of shares on the Samba server with Start -> Run... -> \\bar<ENTER>
- we get an authentication popup and get authenticated correctly
- Works! We can see the list of shares on Samba server "bar", including the share named "foo", which is created by the special Samba [homes] share
- try to access the share named "foo" and get "the network path was not found"
- change /etc/passwd to set foo's home directory to /tmp/foo
- mkdir /tmp/foo, then set owner "foo", group "foo", permissions 755 (rwxr-xr-x)
- restart Samba with "service smb restart" (or "/etc/init.d/smb restart")
- try to access the share named "foo" and it works!
- we even tried creating a share named "blah" pointing to path "/home/blah", with owner, group, perms set for user "foo"
- this fails with "the network path was not found" as above for "/home/foo"
Things we've checked:
- confirmed IP & hostname set correctly in /etc/hosts
- confirmed that we're being authenticated correctly, by trying (and failing) to use an incorrect password for user "foo".
- confirmed that we can use the pre-defined [tmp] share for /tmp
- ran "getfacl /home" and "getfacl /home/foo" and saw nothing weird
- heck, we even ran "lsattr -a /home/foo" in case there was some bizarre attribute affecting us; got "-------------" for everything
So, just for grins, we decided to watch smbd experience the error. Used "strace -p PID" and found this when the XP client tried to access the share named "foo":
...
geteuid32() = 0
getegid32() = 0
setgroups32(1, [500]) = 0
setresgid32(-1, 500, -1) = 0
getegid32() = 500
setresuid32(500, 500, -1) = 0
geteuid32() = 500
stat64("/home/foo", 0xbf9167d4) = -1 EACCES (Permission denied)
...
Note that UID 500 is user "foo" and GID 500 is group "foo". It looks like the file system permissions are blocking us here somehow. What we don't understand is that we can "su - foo" and see everything in /home/foo.
Finally, the problem seems to exist only for certain paths (so far anything under /home and /root).
Thanks in advance to anyone who can shed light on this.
-klode