search for: smbd_check_access_right

...s, which indicates access to the snapdir, .zfs/snapshots, is denied. Error messages: ../source3/modules/vfs_zfsacl.c:56(zfs_get_nt_acl_common) acl(ACE_GETACLCNT, /tank/share/.zfs/snapshot): Operation is not supported on the filesystem where the file reside ../source3/smbd/open.c:128(smbd_check_access_rights) smbd_check_access_rights: Could not get acl on /tank/share/.zfs/snapshot: NT_STATUS_NOT_SUPPORTED ../source3/modules/vfs_shadow_copy2.c:1170(check_access_snapdir) user does not have list permission on snapdir /tank/share/.zfs/snapshot ../source3/modules/vfs_shadow_copy2.c:1339...

Hi all, On Thu, Apr 16, 2015 at 03:00:49PM -0700, Jeremy Allison wrote: > On Thu, Apr 16, 2015 at 08:42:48PM +0200, Ervin Heged?s wrote: > > Dear Samba users, > > > > here is an Ubuntu 14.04, with Samba 4 (4.1.6), and LDAP (slapd > > 2.4.31). The config came from a previous system (Debian Squeezy), > > which had been crashed (HW error - on this new machine,

...sers would not go through SMB_VFS_GET_NT_ACL(), which takes more time on permission checking.[1] Non-admin users would go through SMB_VFS_GET_NT_ACL(), and finally would reach getegid() and geteuid().[2] Hence strace said the top 2 records are getegid() and geteuid(). [1] code snippet: NTSTATUS smbd_check_access_rights(struct connection_struct *conn, ... if (!use_privs && get_current_uid(conn) == (uid_t)0) { /* I'm sorry sir, I didn't know you were root... */ DEBUG(10,("smbd_check_access_rights: root override " "on %s....

..., .zfs/snapshots, is > denied. > > Error messages: > > ../source3/modules/vfs_zfsacl.c:56(zfs_get_nt_acl_common) > acl(ACE_GETACLCNT, /tank/share/.zfs/snapshot): Operation is not > supported on the filesystem where the file reside > ../source3/smbd/open.c:128(smbd_check_access_rights) > smbd_check_access_rights: Could not get acl on > /tank/share/.zfs/snapshot: NT_STATUS_NOT_SUPPORTED > ../source3/modules/vfs_shadow_copy2.c:1170(check_access_snapdir) > user does not have list permission on snapdir /tank/share/.zfs/snapshot > ../source3/module...

...smbclient to attempt to delete a "deleteme" file. I set debug logging to 10 for this example, and collected a client-specific log. I believe the key log line may be line 1599: [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) smbd_check_access_rights: file deleteme requesting 0x10000 returning 0x10000 (NT_STATUS_ACCESS_DENIED) Note that the smbuser UID is 1001, and the smbuser GID is 1001. I've uploaded the full log file to http://n01se.net/paste/Kmz for anyone who would be so kind to offer their expertise....

On 07/26/2016 1:26 PM, Rowland penny wrote: > On 26/07/16 19:08, Jim Seymour wrote: >> On Tue, 26 Jul 2016 12:37:51 -0500 >> Dale Schroeder <dale at BriannasSaladDressing.com> wrote: >> >> [snip] >>> Jim, >>> >>> This may be your problem: Samba 4.3.9 >>> >>> Upgrading my NT4 domain from 4.2.x to 4.3.x and beyond broke

...ot; file. I set debug logging > > to 10 for this example, and collected a client-specific log. I > > believe the key log line may be line 1599: > > > > [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), > > real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) > > smbd_check_access_rights: file deleteme requesting 0x10000 returning > > 0x10000 (NT_STATUS_ACCESS_DENIED) > > > > Note that the smbuser UID is 1001, and the smbuser GID is 1001. > > > > I've uploaded the full log file to http://n01se.net/paste/Kmz fo...

...gt;>> to 10 for this example, and collected a client-specific log. I > >>> believe the key log line may be line 1599: > >>> > >>> [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), > >>> real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) > >>> smbd_check_access_rights: file deleteme requesting 0x10000 returning > >>> 0x10000 (NT_STATUS_ACCESS_DENIED) > >>> > >>> Note that the smbuser UID is 1001, and the smbuser GID is 1001. > >>> > >>> I've uploaded th...

On Mon, Nov 14, 2016 at 11:38:52AM -0500, Josh Malone via samba wrote: > All, > > Apologies for basically bumping my own thread, but I'm absolutely at > my wits' end trying to figure out this access problem. I've > replicated the issue with and without NFS being involved. On our old > 4.0.25 server, users can write to files that they have group-based > write

...elete a "deleteme" file. I set debug logging > to 10 for this example, and collected a client-specific log. I > believe the key log line may be line 1599: > > [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), > real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) > smbd_check_access_rights: file deleteme requesting 0x10000 returning > 0x10000 (NT_STATUS_ACCESS_DENIED) > > Note that the smbuser UID is 1001, and the smbuser GID is 1001. > > I've uploaded the full log file to http://n01se.net/paste/Kmz for > anyone who would be so...

...cess the Profiles share, the user's network home directory, and anything else to which the user should have access. And I can write to those places to which I should be able. At least I don't *think* it's permissions. In perusing the logs, with debug turned up, I see things like smbd_check_access_rights: file username.V2 requesting 0x20080 returning 0x20000 (NT_STATUS_OK) smbd_check_access_rights: file username3.V2 requesting 0x80 returning 0x0 (NT_STATUS_OK) which makes me wonder if the code's not broken. (The thing's lying. The user's id is "Domain User",...

...x, and 4.3.x that permission is not >> being honored. > > > Look for an ACCESS_DENIED. Check the token of the smbd > issuing that error. We check the Windows ACL against > the token before allowing the write. Thank you for that pointer. So, if I take this line for example: smbd_check_access_rights: file . requesting 0x40 returning 0x40 (NT_STATUS_ACCESS_DENIED) [2016/11/14 12:49:21.540401, 10, pid=28398, effective(2310, 2049), real(2310, 0)] ../source3/smbd/open.c:179(smbd_check_access_rights) I see that smbd #28398 is the offending process. I'm not sure what the "token" i...

...t; which takes more time on permission checking.[1] > > Non-admin users would go through SMB_VFS_GET_NT_ACL(), > and finally would reach getegid() and geteuid().[2] > > Hence strace said the top 2 records are getegid() and geteuid(). > > > [1] code snippet: > NTSTATUS smbd_check_access_rights(struct connection_struct *conn, > ... > if (!use_privs && get_current_uid(conn) == (uid_t)0) { > /* I'm sorry sir, I didn't know you were root... */ > DEBUG(10,("smbd_check_access_rights: root override " >...

...#39;s network home directory, and anything else to which the user > should have access. And I can write to those places to which I should > be able. > > At least I don't *think* it's permissions. In perusing the logs, with > debug turned up, I see things like > > smbd_check_access_rights: file username.V2 requesting 0x20080 > returning 0x20000 (NT_STATUS_OK) > smbd_check_access_rights: file username3.V2 requesting 0x80 > returning 0x0 (NT_STATUS_OK) > > which makes me wonder if the code's not broken. (The thing's lying. > The user'...

...set debug logging >>> to 10 for this example, and collected a client-specific log. I >>> believe the key log line may be line 1599: >>> >>> [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), >>> real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) >>> smbd_check_access_rights: file deleteme requesting 0x10000 returning >>> 0x10000 (NT_STATUS_ACCESS_DENIED) >>> >>> Note that the smbuser UID is 1001, and the smbuser GID is 1001. >>> >>> I've uploaded the full log file to http://n01s...

...-2-0 gid 0 (root) SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER ace_flags = 0x0 perms r-x So it's the top-level directory of the share /data/test that is root.root rwxr-xr-x Can you check that ? The open request fails with: smbd_check_access_rights: file . requesting 0x40 returning 0x40 (NT_STATUS_ACCESS_DENIED) 0x40 is SEC_DIR_DELETE_CHILD, which is seeing if a file in that directory can be deleted. As you're not root, that open fails (you don't have 'w' access). Hope this helps.

...to 10 for this example, and collected a client-specific log. I >>>>> believe the key log line may be line 1599: >>>>> >>>>> [2015/04/26 00:07:17.457393, 10, pid=22294, effective(1001, 1001), >>>>> real(1001, 0)] ../source3/smbd/open.c:171(smbd_check_access_rights) >>>>> smbd_check_access_rights: file deleteme requesting 0x10000 returning >>>>> 0x10000 (NT_STATUS_ACCESS_DENIED) >>>>> >>>>> Note that the smbuser UID is 1001, and the smbuser GID is 1001. >>>>> >>>>> I...

...ETER; > } > > - if(!S_ISDIR(smb_dname->st.st_ex_mode)) { > - DEBUG(5,("open_directory: %s is not a directory !\n", > - smb_fname_str_dbg(smb_dname))); > - return NT_STATUS_NOT_A_DIRECTORY; > - } > - > if (info == FILE_WAS_OPENED) { > status = smbd_check_access_rights(conn, > - smb_dname, > - false, > - access_mask); > + smb_dname, > + false, > + access_mask); > if (!NT_STATUS_IS_OK(status)) { > DEBUG(10, ("open_directory: smbd_check_access_rights on " > - "file %s failed wi...

...>being honored. > > > > > >Look for an ACCESS_DENIED. Check the token of the smbd > >issuing that error. We check the Windows ACL against > >the token before allowing the write. > > Thank you for that pointer. So, if I take this line for example: > > smbd_check_access_rights: file . requesting 0x40 returning 0x40 > (NT_STATUS_ACCESS_DENIED) > [2016/11/14 12:49:21.540401, 10, pid=28398, effective(2310, 2049), > real(2310, 0)] ../source3/smbd/open.c:179(smbd_check_access_rights) > > I see that smbd #28398 is the offending process. I'm not sure what &...

...> > So it's the top-level directory of the share > /data/test > > that is root.root rwxr-xr-x > > Can you check that ? Nope - that directory is uid 2310, group 9004. I'm in group 9004. How can samba be getting that wrong? > The open request fails with: > > smbd_check_access_rights: file . requesting 0x40 returning 0x40 (NT_STATUS_ACCESS_DENIED) > > 0x40 is SEC_DIR_DELETE_CHILD, which is seeing if a file in that > directory can be deleted. As you're not root, that open fails > (you don't have 'w' access). > > Hope this helps. Okay - I under...