• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1857 views
  • Users 0 members are here
Options
Related
This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Unable to access network smb shares using Serv-U

crypt0

I have a few Serv-U setups running, and some of them are using external smb shares like NAS or windows file shares requiring authentication.
My Serv-U servers are not domain joined and my serv-u services are running as a local service account on the server. My storage solutions are often domain joined or at least using ldap for authentication users requiring me to use a domain account to access the share.
If i'm on the server trying to access the share i get prompt for user/pw. After user/pw input i can access the share.
Using the same logic I'm able to add the share as a persistent disk or even add my credentials using cmdkey as the same user running serv-u service. This allows me to access the share in windows, however wont have any effect in Serv-U it seems.

Going into Serv-U Management - Adding the share as a directory, entering user/pw/domain should have given me the same behaviour. However it seems this have no effect. 
Adding the share as homedirectory on one of my users, or as a addon directory using virtual directory gives me an error that the directory does not exist or no error just not showing up in the list as all.
The same goes for domain directory rules adding the share with user/pw/domain with no effect

I'm guessing had I had my server and NAS joined to the same domain and had my services run as the same user having access to the share this would work. However this is not an option.

Using the method above seem to have worked on previous versions of Serv-U Version 15.2 (15.2.3.742) and older. I'm currently on 15.4 and had the same issue on 15.3.

Errors:

[02] Thu 01Jun23 15:33:22 - (000073) Error logging in user "USERNAME", home dir "\\domain.local\data\SFTP\" does not exist
Parents
  • 0

    Hi . I'm not sure if you were referring to a mapped drive when you said persistent disk, mapped drives wont work as they are only in the "current user" context so Serv-U wouldnt see the drive.

    Can you tell us how you are adding the 'share' in Serv-U for access. How are you providing the credentials for the path for Serv-U to access it?

  • 0 in reply to calc2014

    Hi
    Sorry for being a bit short when describing the issue earlier. 

    I have tried to provide the credentials both on Windows side and from Serv-U. In Serv-U I have tried adding the share as a directory under Domain -> "Directories" as well as from Domain -> Users -> *USER* -> Directory.
    Both places I provided username, password and domain. However none of these seem to make any difference.

    Previously I added the credentials to the share, both providing hostname and fqdn. By running cmd as the same local user running my Serv-U service and using cmdkey to store credentials. This did work a few versions ago.

  • 0 in reply to crypt0

    No worries, A few versions back there was a change in the release notes relating to the user Serv-U is running under. Have you checked that since you upgraded and had this issue?

  • 0 in reply to calc2014

    Yeah, am aware of that and have been seeking solutions for how to work around it. However I have yet to work out any alternatives.
    In reality, you should be able to add a datasource to a mft product for sharing data. However Serv-U seems to be lacking support for adding sources outside the OS without removing authentication that is.

  • 0 in reply to crypt0

    Just for the purposes of verifying that this is the issue, have you tried changing the service account back to what it was and doing your test on the current version?

  • 0 in reply to calc2014

    I think my setup is more or less default. I also have Serv-U setups brand new where I would like to add new shares. However i'm facing the same issues on these am afraid. 

  • 0 in reply to crypt0

    If you were on a previous version and upgraded, the service account may have been changed. Have you checked it?

  • 0 in reply to calc2014

    Sure. When upgrading from an older version it got changed to "network service". However I have a few newer Serv-U setups having the same problem, both running as a network service and a local service. It seems whatever i input regards to credentials for directories it just ignores it. Removing authentication on share seems to work tho..

  • 0 in reply to crypt0

    Ah I see. So it works ok when the service account is reverted but when specifying a different account in "Directories" it does not make the connection using those details?

    Have you ever used this "Directories" method, even in previous versions? I havent had a need to use it myself.

    Also, have you raised this with Solarwinds support?

  • 0 in reply to calc2014

    No, it does not work whatever I try. (Only option seem to be to remove authentication from external share)
    How would you add external share or datasources to users in Serv-U?. (Ex Azure blobs, smb/cifs shares,, etc..)

    Yes I have a ongoing ticket with Solarwinds. Lets see what they say.

  • 0 in reply to crypt0

    I've had a double check in the documentation and the method you Described in 'Directories' is documented but it does have some notes:

    https://documentation.solarwinds.com/en/success_center/servu/content/servu-domain-directories-directory-access.htm

    --

    The alternative, preferred where many servers exist, or if the SolarWinds Serv-U File Server service has to run under Local System for security reasons, is to configure a directory access rule to use a specific Windows user for file access. Click Advanced to specify a specific Windows user for each directory access rule. As in Windows authentication, directory access is subject to NTFS permissions, and in this case also to the configured permissions in Serv-U File Server.

    When you use Windows authentication, the NTFS permissions of the Windows user take priority over the directory access rules. This means that when a Windows user tries to access a folder, the security permissions of the user are applied instead of the credentials specified in the directory access rule.

    --

    If that doesnt work, please let us know what Solarwinds Support say so that it is documented for other users.

    Hope this helps.

  • 0 in reply to calc2014

    Thanks for you effort here Appreciated.

    The approach above is part of the different scenarios I have tested. Defining a domain user under advanced or not seem to make no difference both when running as network service or local windows user.

    I'm starting to think I'm doing something wrong, wanting to use external/not directly attached storage to a MFT solution :-)

    I will indeed update you guys when I hear back from support.

Reply
  • 0 in reply to calc2014

    Thanks for you effort here Appreciated.

    The approach above is part of the different scenarios I have tested. Defining a domain user under advanced or not seem to make no difference both when running as network service or local windows user.

    I'm starting to think I'm doing something wrong, wanting to use external/not directly attached storage to a MFT solution :-)

    I will indeed update you guys when I hear back from support.

Children
No Data

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification SolarWinds Lab Link Accounts
About THWACK Blogs Federal & Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2021 SolarWinds Worldwide, LLC. All Rights Reserved.