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
> 
>