192.168.1.26 05/03/2014 05:30:29 OURSERVER system Error smbd18085 "[2014/03/05 05:30:29.621556, 0] ../lib/util/talloc_stack.c:104(talloc_pop)"
192.168.1.26 05/03/2014 05:30:29 OURSERVER system Error smbd18085 "Freed frame ../source3/smbd/open.c:3510, expected ../source3/modules/nfs4_acls.c:936."
FreeNAS bug report:
What do you need to debug this?
What this means is somewhere in the code there's a missmatch between a :
TALLOC_CTX *frame = talloc_stackframe();
... code stuff..
frame pair. So the frame is leaking out into the caller (open.c in this case).
Can you send me the *exact* version of source3/modules/nfs4_acls.c you're compiling with
so I can check. I checked out the git branch of 4.1.5 and that code does use talloc_stackframes, but in every code path
from every function that creates a talloc_stackframe I see an associated TALLOC_FREE(frame),
so I really need to see what you're using.
As I recall there was a bug in this very code which sounds like what you're seeing, but it was fixed. Are you sure you're running 4.1.5 ?
Created attachment 9752 [details]
requested source file
We are running 4.1.5 with some changes cherry-picked in.
[jpaetzel@c0mmander] ~/sambasrc/samba-4.1.5% diff -u /freenas/BSD/releng/FreeNAS/build_env/18.104.22.168-RELEASE/os-base/amd64/_.w/usr/workdir/usr/ports_dir/net/samba41/work/samba-4.1.5/source3/modules/nfs4_acls.c source3/modules/nfs4_acls.c
Just for kicks I double checked the build source versus a stock samba 4.1.5 tarball.
Ok, this is really hurting my brain :-). I can't see where there's a frame missmatch. Much be in the lower layers. I'll look further.
Can you add the smb.conf (and the specific share the user is connected to) please. I really need to see what modules are loaded on this share.
Is it possible that on install of a new Samba version you're not overwriting the VFS modules correctly ?
I ask as this was a bug that existed in exactly this area (a danging frame pointer) that was fixed a while ago.
Also a debug level 10 log with this being reproduced would really help.
path = /mnt/pool/share
printable = no
veto files = /.snap/.windows/.zfs/
comment = Carpeta compartida comÃºn
writeable = yes
browseable = yes
recycle:repository = .recycle/%U
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = yes
recycle:directory_mode = 0777
recycle:subdir_mode = 0700
vfs objects = zfsacl streams_xattr aio_pthread
hide dot files = yes
guest ok = no
inherit acls = yes
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
zfsacl:acesort = dontcare
There is no chance there's a module mismatch. FreeNAS images are a read only blob that is distributed in one chunk.
I'll request the log info
I'm seeing this issue on Freenas 9.2.2 as well, trying to create a Hyper-V .vhdx on an SMB3 share.
the freenas link to the main bug description ends in a 404 these days and the discussion here also just ended shortly after it started, closing this bug also.