[Samba] Re: locking.tdb: expand_file ftruncate to 8192 failed (Permission denied)

[Axel Thimm]

On Wed, Sep 21, 2005 at 04:34:32PM -0700, Jeremy Allison wrote:
> On Thu, Sep 22, 2005 at 01:01:45AM +0200, Axel Thimm wrote:
> > Should I generate a more verbose debug log (what log level
> > settings?) and place it somewhere on the net?
> > 
> > I wonder how I'm triggering that code path, it certainly isn't seen by
> > the typical RHEL4 installs. The lock directory is set to reside on a
> > GFS filesystem, could that make a difference (shouldn't as it is
> > supposed to be POSIX compliant local-fs-like filesystem)?
> 
> Oh almost certainly that's the problem. Did you test my test program
> on a GFS filesystem ? Doesn't GFS use crypto credentials to prevent
> people hijacking root ? If that's the case I bet they break POSIX
> semantics w.r.t. this.
> 
> Why are you putting the locking db on a GFS filesystem anyway. That's
> madness !

The reason is to have a poor-man's-clustered-samba by placing lock and
private dir on a common share and have the relocated smbd/nmbd pairs
access them. E.g. relocating within the cluster is effectively like
restarting smbd/nmbd on a node.

On Wed, Sep 21, 2005 at 04:37:32PM -0700, Jeremy Allison wrote:
> On Thu, Sep 22, 2005 at 01:09:30AM +0200, Axel Thimm wrote:
> > # mount | grep gfs
> > /dev/mapper/physik-data on /srv/physik.fu-berlin.de/data type gfs
> > (rw,acl)
> > # pwd
> > /srv/physik.fu-berlin.de/data/samba-test
> > # ls -l
> > total 32
> > -rwxr-xr-x  1 root root 10080 Sep 22 00:38 a.out
> > -rw-------  1 root root  1231 Sep 22 00:35 test.c
> > -rw-r--r--  1 root root     0 Sep 22 01:07 testfile
> > # ./a.out testfile thimm
> > Segmentation fault
> 
> What's the gdb backtrace. There's probably a bug in one of
> the error condition printing in the test code.

(gdb) run testfile thimm
Starting program: /srv/physik.fu-berlin.de/data/samba-test/a.out testfile thimm

Program received signal SIGSEGV, Segmentation fault.
0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
#1  0x0000003e18a428dc in vfprintf () from /lib64/tls/libc.so.6
#2  0x0000003e18a3f299 in buffered_vfprintf () from /lib64/tls/libc.so.6
#3  0x0000003e18a3f479 in vfprintf () from /lib64/tls/libc.so.6
#4  0x0000003e18a47d96 in fprintf () from /lib64/tls/libc.so.6
#5  0x0000000000400b2b in main (argc=3, argv=0x7fbffff8a8) at test.c:55

> As I said, I bet GFS isn't POSIX complient. Don't put locking
> tdb's on anything but local filesystems.

Well, GFS claims to be POSIX and local-like in any way. Maybe it is
just a bug in GFS? Does POSIX ensure that you can open an fd under
some user and not lose access right to the fd when dropping
priviledges?

Thanks!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20050922/83f8b152/attachment.bin