similar to: Weirdness with cifs.idmap

New version 6.10 of cifs-utils has been released. Highlighted changes: - smb3 alias/fstype is added - smb2-quota tool is added to display quota information - smb2-secdesc UI tool to view security descriptors is added - smbinfo is enhanced with capabilities to dump session keys and get/set compression of files - smbinfo bash completion is supported - getcifsacl tool is improved to support

Hi When I mount CIFS share (mount -t cids) with vers=1.0 I can perform getcifsacl sucessfully. But when I mount with vers=2.0, or 2.1, or 3.0, ACL reading fails. getxattr error: 95 REVISION:0x0 CONTROL:0x0 Why getcifsacl depends on SMB protocol version? Can I read ACL via newer SMB protocol? A asked on Serverfault but without reply:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Time for another cifs-utils release! Most of the patches in this release are for cifs.idmap, getcifsacl and setcifsacl. There were many bugs in those tools, so anyone that's deploying or using them is highly encouraged to upgrade. Highlights: * NFS-style device names are being deprecated in 6.0. Anyone using that sort of device name should

On Wed, 23 Jan 2019 09:47:11 +0100 Miloslav Hůla via samba <samba at lists.samba.org> wrote: > Dne 2019-01-15 v 13:22 Miloslav Hůla via samba napsal(a): > > When I mount CIFS share (mount -t cids) with vers=1.0 I can perform > > getcifsacl sucessfully. But when I mount with vers=2.0, or 2.1, or > > 3.0, ACL reading fails. > > > > getxattr error: 95 >

This is a big release that contains many functional changes that are aligned with the recent work done in the Linux SMB3 kernel client. These changes mostly aim to improve user experience by unlocking new features available in modern SMB3 servers: - smbinfo utility is added to query various kinds of information from the server (objectId, snapshots, different FileInfo* classes and other

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Time for a new cifs-utils release! The big bullet point in this release is a new pam_cifscreds module that has been added by Orion Poplawski. This release also cleans some unused cruft out of some of the binaries so they're quite a bit smaller now and fixes a few bugs that Coverity turned up. Go forth and download! webpage:

We've had a number of changes since the last release, and we have some other upcoming kernel changes that might require corresponding cifs-utils changes. So it's probably as good a time as any for a new release. Highlights: + fix for a minor security issue that can corrupt the mtab + new getcifsacl/setcifsacl tools that allow you to fetch and set raw Windows ACLs via an xattr. + a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With the merge of the new plugin interface, it's probably a good time for a new cifs-utils release. Distro packagers should take special note of the changes with the new plugin interface since it has implications for how the tools are packaged. In particular, it's necessary to set a symlink to the plugin in the correct location

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Things have been relatively quiet lately. Time for a release! Highlights: * A lot of manpage updates, additions and corrections * cifs.idmap can now map uid/gid to SID in addition to the other way around * getcifsacl/setcifsacl are now installed by default in /usr/bin instead of /usr/sbin. The manpages are now in section 1. * cifs.upcall has a

On 25/09/2020 17:15, Ken Bass via samba wrote: > On 9/25/20 5:14 AM, Aur?lien Aptel wrote: >> Ken Bass via samba <samba at lists.samba.org> writes: >>> Can you please expand on this, I am confused as to what you are >>> suggesting.? If 'getent pass' works properly and shows no >>> overlap/confusion, this seems to be related to cifsacl. >>

On 9/25/20 5:14 AM, Aur?lien Aptel wrote: > Ken Bass via samba <samba at lists.samba.org> writes: >> Can you please expand on this, I am confused as to what you are >> suggesting.? If 'getent pass' works properly and shows no >> overlap/confusion, this seems to be related to cifsacl. > It's still hard to say at this point. > > cifs.idmap logs

Sometimes a group sid does not get resolved to its name. Is this a settings problem? Looks like winbind deamon went dormant for a while and then woke up? I am using interface wbcLookupSid provided by the library libwbclient.so for resolving sids to names. These are the winbind related parameters in /etc/samba/smb.conf [global] # separate domain and username with '\', like

Dear Jeremy, thanks for your instant reply. :-) Along with Linux native getfacl/fetfacl, I also tested getcifsacl/setcifsacl (for sure thoroughly ;-)). Unfortunately, these CIFS client tools seem to have been designed as part of the "old" CIFS Unix Extensions, working only for SMB/CIFS mounts, and are not supposed to work with SMB2/SMB3 mounts, as I guess. During my tests, the

On 9/25/20 12:23 PM, Rowland penny via samba wrote: > On 25/09/2020 17:15, Ken Bass via samba wrote: >> On 9/25/20 5:14 AM, Aur?lien Aptel wrote: >>> Ken Bass via samba <samba at lists.samba.org> writes: >>>> Can you please expand on this, I am confused as to what you are >>>> suggesting.? If 'getent pass' works properly and shows no

Hi, I have a regression test suite that creates this simple share: [tmp] comment = Temp Directory guest ok = Yes path = /tmp read only = No This is mounted via SMB1: mount //localhost/tmp -o guest,vers=1.0 /mnt The client (ubuntu 18.10 dev) is using cifs-utils 2:6.8-2 from debian (it's a sync). Client and server are the same machine (localhost). When the server is

Could you see if anything useful in the logs indicating why the ACL was not returned? Instructions are at: https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging (it is easier for newer kernels due to dynamic tracing e.g. "trace-cmd record -e cifs" but even with these older kernels it should be enough information in the dmesg logs - if not a wireshark trace

Hi Jeremy, Hi Steve, Hi Ronnie, thanks for your replies and the profound discussion. I think, it's best to demonstrate my problem case along an real world example: The following log of a console sesssion shows how I am doing the mounts on behalf Linux Kernel CIFS-FS Module on the client side against a Samba 4.5 file server (both running on Debian Stretch 9.8) via SMB/CIFS resp. SMB2 protocol:

I've done a lot of research on this and haven't been able to solve the problem. Hopefully someone here has a better understanding of this than I do. The problem is that the UIDs and GIDs are not being fetched from AD. For example "getent passwd doug" returns: doug:*:70003:70005:Doug Meredith:/home/DSTRC/doug:/bin/false My full name has correctly been pulled from AD but the

On Tue, Feb 26, 2019 at 09:03:41AM -0800, Jeremy Allison via samba wrote: > > Check out the latest cifsfs code. I think Steve > and Aurelian and Ronnie added an ioctl for this. > > I'm here at Vault in Boston with Steve, I'll ask > him :-). Steve says there are two utilities in Linux, getcifsacl and setcifsacl that use a custom ioctl inside the Linux cifsfs kernel

Hello, On Debian 9 (stretch prerelease) I am able to mount with the following command with root using the following command: mount -t cifs //smb.physics.wisc.edu/smb /smb -osec=krb5,multiuser,username=smbadmin at PHYSICS.WISC.EDU --verbose root can also access files as expected However, when cifs-utils 6.6-5 is installed, a different user cannot access as expected: ls /smb ls: cannot