First, some background.
We have a Linux server (CentOS 7.3.1611, Samba 4.4.4, sssd 1.14.0) that is
providing access vis SMB to various file systems (home folders on NetApp filer,
shared data stored on SwiftStack), and joined to our Active Directory. Clients
connecting to it are Windows 7 or 10 (mostly Win10), or OS X Macs running ... El
Capitan or Sierra or High Sierra). Our problem is that we get reports from some
clients that they've lost connection and when they try to remap the drive,
they get access denied or other generic error messages. Meanwhile, other
clients continue to access their storage through this Samba server with no
issues. Logs don't actually seem to point to any specific issues.
Sometimes restarting sssd is sufficient. Other times, we've had to actually
remove the Linux server from our Active Directory and rejoin it -- which
disconnects everybody.
So, I built a second Linux Server (Ubuntu 16.04.2 LTS, Samba
2.4.3.11+_dfsg-0ubuntu0.16.04.12, sssd 1.13.4-lubuntu1.10) to see if I get
different results. I joined it to our AD. This one seems more stable .... but I
have a Win10 test user who reports getting disconnected with popups complaining
that "the directory name is invalid" or "the handle is
invalid". Sometimes the user is working actively in the directory in
question. Sometimes it is just connected, but he is off doing something else.
Again, logs are unhelpful -- even with log level = 5.
One of the main reasons we're doing this is that the home drives in question
are often accessed from Linux, and so there are softlinks to other file systems.
So, users have a bunch of softlinks pointing to directories on different file
systems and access them by first going to their home directory, then clicking on
the softlink so that they end up where they want to go, regardless of whether
they are on a Mac or a Windows machine (hence "follow symlinks = yes"
in smb.conf below.
Any thoughts or suggestions on what I should look at next would be appreciated.
Thanks,
-p
smb.conf:
[global]
workgroup = XXXXX
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = XXXXX.ORG
security = ads
unix extensions = no
follow symlinks = Yes
wide links = yes
allow insecure wide links = yes
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 50000
syslog = 0
panic action = /usr/share/samba/panic-action %d
log level = 5 passdb:5 auth:5
server role = member server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:*
%n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
[home]
path = /home/%U
read only = No
create mask = 0664
directory mask = 02775
inherit acls = Yes
case sensitive = No
veto files = /.tnatr:*/
map readonly = permissions
mangled names = No
browseable = Yes
wide links = Yes
follow symlinks = Yes
dos filemode = Yes
[homes]
comment = %U's Home Directory
path = /home/%U
read only = No
create mask = 0664
directory mask = 02775
inherit acls = Yes
case sensitive = No
veto files = /.tnatr:*/
map readonly = permissions
mangled names = No
public = No
browseable = Yes
writeable = Yes
dos filemode = Yes
follow symlinks = Yes
wide links = Yes
--
Pat Hirayama
Systems Engineer / 206.667.4856 / phirayam at fredhutch.org / Fred Hutch / Cures
Start Here
CIT | Advancing IT and Data Services to Accelerate the Elimination of Disease
On Thu, 1 Mar 2018 00:51:42 +0000 "Hirayama, Pat via samba" <samba at lists.samba.org> wrote:> First, some background. > > We have a Linux server (CentOS 7.3.1611, Samba 4.4.4, sssd 1.14.0) > that is providing access vis SMB to various file systems (home > folders on NetApp filer, shared data stored on SwiftStack), and > joined to our Active Directory. Clients connecting to it are Windows > 7 or 10 (mostly Win10), or OS X Macs running ... El Capitan or Sierra > or High Sierra). Our problem is that we get reports from some > clients that they've lost connection and when they try to remap the > drive, they get access denied or other generic error messages. > Meanwhile, other clients continue to access their storage through > this Samba server with no issues. Logs don't actually seem to point > to any specific issues. Sometimes restarting sssd is sufficient. > Other times, we've had to actually remove the Linux server from our > Active Directory and rejoin it -- which disconnects everybody. > > So, I built a second Linux Server (Ubuntu 16.04.2 LTS, Samba > 2.4.3.11+_dfsg-0ubuntu0.16.04.12, sssd 1.13.4-lubuntu1.10) to see if > I get different results. I joined it to our AD. This one seems more > stable .... but I have a Win10 test user who reports getting > disconnected with popups complaining that "the directory name is > invalid" or "the handle is invalid". Sometimes the user is working > actively in the directory in question. Sometimes it is just > connected, but he is off doing something else. Again, logs are > unhelpful -- even with log level = 5. > > One of the main reasons we're doing this is that the home drives in > question are often accessed from Linux, and so there are softlinks to > other file systems. So, users have a bunch of softlinks pointing to > directories on different file systems and access them by first going > to their home directory, then clicking on the softlink so that they > end up where they want to go, regardless of whether they are on a Mac > or a Windows machine (hence "follow symlinks = yes" in smb.conf below. > > Any thoughts or suggestions on what I should look at next would be > appreciated. >You are having what appears to be authentication problems, so you need to deal with what is doing your authentication and it isn't Samba ;-) Your authentication is being done by sssd, so I suggest you ask on the sssd-users mailing list. Rowland
On Fri, 16 Mar 2018 19:55:58 +0000 "Hirayama, Pat" <phirayam at fredhutch.org> wrote:> Thanks, Rowland. > > So, after poking around SSSD configuration for a bit, I just ripped > it out and replaced it with LDAP. It (or something similar) is still > happening. > > User opened up a window on the Samba server, verifying that he could > access files around 11:30 am this morning. 20 minutes later, he > tried again (he had left the folder open in Windows Explorer) and > received a "Network Error" message that "You do not have permission > to access \\(path). Contact your network administrator to request > access." > > Does it still seem like it would be authentication that is the root > cause? >Have you considered using the Samba method for authentication 'winbind' ?? Can you also post your smb.conf ? Rowland
On Fri, 16 Mar 2018 20:24:47 +0000 "Hirayama, Pat" <phirayam at fredhutch.org> wrote:> In the past I've used winbind -- though, I've had issues where it > just stops working until the service is restarted again. Was hoping > to get away from that, hence trying sssd and ldap with Kerberos. >This sometimes happened in the early days of Samba 4, but it isn't a problem now. Try this smb.conf, I have removed all the default settings, but you will need to uncomment one of the 'idmap conf DOMAIN' blocks, see the inline comments. [global] security = ADS workgroup = XXXXX realm = XXXXX.ORG server role = member server server string = %h server (Samba) log level = 2 max log size = 1000 server min protocol = SMB2_10 ntlm auth = no idmap config * : backend = tdb idmap config * : range = 3000-4999 restrict anonymous = 2 # You seem to like living dangerously # Do you really need the wide links ? unix extensions = no wide links = yes allow insecure wide links = yes idmap config * : backend = tdb idmap config * : range = 3000-4999 ### As you are using Samba 4.4.4 on your centos 7 machine ### Uncomment one of the following # # 'ad' backend # If uidNumber & gidNumber attributes in AD # They must be inside 5000-1999999 # winbind nss info = rfc2307 #idmap config XXXXX:backend = ad #idmap config XXXXX:range = 5000-1999999 #idmap config XXXXX:schema_mode = rfc2307 # # 'rid' backend # if NO uidNumber or gidNumber attributes in AD #idmap config XXXXX:backend = rid #idmap config XXXXX:range = 5000-1999999 # load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes # For ACL support on domain member vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes # These should be in 'shares' #create mask = 0664 #force create mode = 0664 #directory mask = 2770 #force directory mode = 2770 # You only need one !! # '[home]' for preference # '[homes]' doesn't really work with AD [home] ###comment = %U's Home Directory path = /home/%U read only = No create mask = 0664 directory mask = 02775 inherit acls = Yes case sensitive = No veto files = /.tnatr:*/ mangled names = No wide links = Yes follow symlinks = Yes dos filemode = Yes #[homes] # comment = %U's Home Directory # read only = No # create mask = 0664 # directory mask = 02775 # inherit acls = Yes # case sensitive = No # veto files = /.tnatr:*/ # mangled names = No # dos filemode = Yes # follow symlinks = Yes # wide links = Yes Rowland
On Fri, 16 Mar 2018 21:43:39 +0000 "Hirayama, Pat" <phirayam at fredhutch.org> wrote:> Hi Rowland, > > Thank you. Unfortunately, I do need widelinks -- in fact, that is > the main purpose for this Samba server -- the users connect to their > home share and follow the Linux symlinks that reside there to other > (remote) file systems, rather than navigating a really long directory > path.There must be a better way of doing this, dfs shares ??> > And while I am running Samba 4.4 on CentOS 7, the test/replacement > box that I am working with is Samba 4.3 on Ubuntu 16.04 LTS. Should I > still uncomment one of those idmap entries?I would go to Ubuntu 18.04, this will get you a Samba supported version, both 4.3.x & 4.4.x are EOL as far as Samba is concerned. If you do go with 18.04, you will need to make some changes to the 'ad backend lines, use these instead: # 'ad' backend # If uidNumber & gidNumber attributes in AD # They must be inside 5000-1999999 #idmap config XXXXX:backend = ad #idmap config XXXXX:range = 5000-1999999 #idmap config XXXXX:schema_mode = rfc2307 #idmap config XXXXX:unix_nss_info = yes # If you want to use another group for the # users primary group instead of Domain Users # uncomment the next line as well #idmap config XXXXX:unix_primary_group = yes And yes you do need the lines, winbind will not work without them, you just need the right lines depending on the backend type and if 'ad', the right lines for the Samba version.> > Oh, and the home/homes shares seem to work because they are being > served from a NetApp. At least, that's what one of our storage > engineers once told me. >Well yes, but probably because you had 'path' in the [homes] share, which is not normally used. Rowland
On Fri, Mar 16, 2018 at 10:13:07PM +0000, Rowland Penny via samba wrote:> On Fri, 16 Mar 2018 21:43:39 +0000 > "Hirayama, Pat" <phirayam at fredhutch.org> wrote: > > > Hi Rowland, > > > > Thank you. Unfortunately, I do need widelinks -- in fact, that is > > the main purpose for this Samba server -- the users connect to their > > home share and follow the Linux symlinks that reside there to other > > (remote) file systems, rather than navigating a really long directory > > path. > > There must be a better way of doing this, dfs shares ??+1 to that - DFS links are a *much* safer way of doing this. Don't follow symlinks outside the share, that's evil and will eventually bite you.