Looks like samba tries to be too smart :/ The only thing which can help to it - clustered file system like GFS which won't change inode numbers across nodes... As another option - VE in a file (via loopbacks) which we plan to implement in nearest future.
Thanks, Kirill Jeff Blasius wrote: > Dear Users, > I find that after live migrating a container samba refuses to accept > new connections (existing connections continue to work properly). I > traced it back to this message in the logs which says " > tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has > changed!" . Of course the inode changed, but does it need to panic... > Is there a workaround? > > I'd be willing to bet someone has come across this before, but I > couldn't find an answer on the wiki or the list archives. > > Centos 5 > samba-3.0.25b-1.el5_1.4 > vzctl-3.0.18-1 > Thanks, > jeff > > [2008/01/22 11:53:46, 0] lib/util_tdb.c:tdb_log(662) > tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has changed! > [2008/01/22 11:53:46, 0] smbd/server.c:open_sockets_smbd(572) > tdb_reopen_all failed. > [2008/01/22 11:53:46, 0] lib/util.c:smb_panic(1654) > PANIC (pid 22099): tdb_reopen_all failed. > [2008/01/22 11:53:46, 0] lib/util.c:log_stack_trace(1758) > BACKTRACE: 6 stack frames: > #0 smbd(log_stack_trace+0x1c) [0x555555776ffc] > #1 smbd(smb_panic+0x43) [0x5555557770e3] > #2 smbd [0x55555582ac3a] > #3 smbd(main+0x710) [0x55555582b370] > #4 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaad3818a4] > #5 smbd [0x5555555bbfe9] > [2008/01/22 11:53:46, 0] lib/fault.c:dump_core(181) > dumping core in /var/log/samba/cores/smbd > > _______________________________________________ Users mailing list [email protected] https://openvz.org/mailman/listinfo/users
