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: https://bugs.freenas.org/issues/4476 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.. TALLOC_FREE(frame); 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 ? Jeremy.
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/9.2.1.2-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 [jpaetzel@c0mmander] ~/sambasrc/samba-4.1.5% Just for kicks I double checked the build source versus a stock samba 4.1.5 tarball. No diffs
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. Thanks ! Jeremy.
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. Jeremy.
[SHARE] 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.