Problem with F7 and Samba 3.0.27
Greetings!
I've been using Samba successfully for years, but I've run into a problem for which I could use some expert debugging ideas. I've got a Fedora 7 server sharing the root of its filesystem. I've been using "force user = root" in the smb.conf file so that filesystem permissions are never an issue (this is a single-user machine on an isolated network, so security isn't really a concern). This worked fine until recently. I updated recently to Samba 3.0.27 (using the standard "yum update" mechanism on Fedora to pick up new packages). I don't know exactly what I was running before, but I presume it was some version of 3.0.26; I apply updates regularly. I didn't find any mention of changed "force user" behavior in the 3.0.27 release notes. In any case, I can still authenticate, and I can still access the filesystem, but not with root's permissions (nor those of the user who authenticates). I've checked logs (at both normal and elevated debugging levels) and can't see any obvious evidence of a problem. But clearly smbd is now having problems assuming the identity of the root user. Can anyone offer suggestions as to how I might seek to isolate the source of this problem? Here's the relevant section of the smb.conf file. As I mentioned earlier, I can authenticate without difficulty; I just don't get the right set of permissions after doing so. SELinux is off, so that's not the cause. [gwroot] browseable = yes writable = yes path = / guest ok = no comment = Root valid users = psw force user = root Thanks for any suggestions! Phil Wherry -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list |
Problem with F7 and Samba 3.0.27
Phil Wherry wrote:
> Greetings! > > I've been using Samba successfully for years, but I've run into a > problem for which I could use some expert debugging ideas. > > I've got a Fedora 7 server sharing the root of its filesystem. I've > been using "force user = root" in the smb.conf file so that filesystem > permissions are never an issue (this is a single-user machine on an > isolated network, so security isn't really a concern). This worked > fine until recently. > > I updated recently to Samba 3.0.27 (using the standard "yum update" > mechanism on Fedora to pick up new packages). I don't know exactly > what I was running before, but I presume it was some version of > 3.0.26; I apply updates regularly. I didn't find any mention of > changed "force user" behavior in the 3.0.27 release notes. > > In any case, I can still authenticate, and I can still access the > filesystem, but not with root's permissions (nor those of the user who > authenticates). I've checked logs (at both normal and elevated > debugging levels) and can't see any obvious evidence of a problem. But > clearly smbd is now having problems assuming the identity of the root > user. > > Can anyone offer suggestions as to how I might seek to isolate the > source of this problem? > > Here's the relevant section of the smb.conf file. As I mentioned > earlier, I can authenticate without difficulty; I just don't get the > right set of permissions after doing so. SELinux is off, so that's not > the cause. > > [gwroot] > browseable = yes > writable = yes > path = / > guest ok = no > comment = Root > valid users = psw > force user = root > > Thanks for any suggestions! > > Phil Wherry With each update of Samba, there's always a slight risk of samba.conf options changing slightly. I recommending running the samba suite "testparm" command to see if anything gets flagged. Eric Feldhusen -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list |
Problem with F7 and Samba 3.0.27
Eric,
Thanks. I should have mentioned in my original email that "testparm" worked fine, and that it shows the "force user" directive as I'd expect. Phil On Nov 20, 2007, at 9:48 PM, Eric Feldhusen wrote: Phil Wherry wrote: Greetings! I've been using Samba successfully for years, but I've run into a problem for which I could use some expert debugging ideas. I've got a Fedora 7 server sharing the root of its filesystem. I've been using "force user = root" in the smb.conf file so that filesystem permissions are never an issue (this is a single-user machine on an isolated network, so security isn't really a concern). This worked fine until recently. I updated recently to Samba 3.0.27 (using the standard "yum update" mechanism on Fedora to pick up new packages). I don't know exactly what I was running before, but I presume it was some version of 3.0.26; I apply updates regularly. I didn't find any mention of changed "force user" behavior in the 3.0.27 release notes. In any case, I can still authenticate, and I can still access the filesystem, but not with root's permissions (nor those of the user who authenticates). I've checked logs (at both normal and elevated debugging levels) and can't see any obvious evidence of a problem. But clearly smbd is now having problems assuming the identity of the root user. Can anyone offer suggestions as to how I might seek to isolate the source of this problem? Here's the relevant section of the smb.conf file. As I mentioned earlier, I can authenticate without difficulty; I just don't get the right set of permissions after doing so. SELinux is off, so that's not the cause. [gwroot] browseable = yes writable = yes path = / guest ok = no comment = Root valid users = psw force user = root Thanks for any suggestions! Phil Wherry With each update of Samba, there's always a slight risk of samba.conf options changing slightly. I recommending running the samba suite "testparm" command to see if anything gets flagged. Eric Feldhusen -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list |
| All times are GMT. The time now is 11:59 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.