Jump to content


CudaLaunch - No access to SMB share after migrating file server

  • Please log in to reply
3 replies to this topic

#1 JeWe

  • Members
  • 96 posts
  • LocationGermany, NDS

Posted 27 June 2018 - 07:53 AM



we use CudaLaunch (latest version 2.5.2) for accessing our file share via internet. Before, the share was located on a Windows Server 2008 and it worked fine. Now I migrated the file server to a Synology NAS, the access rights are OK, doublechecked this. Access is given from Windows domain user's credentials.


On our NG400, I configure the network places, just changing File Server Host (IP), File Server Path is unchanged. I can log in without any problems, but afterwards, choosing Folder and klicking on the share, I get "Invalid credentials". Give it another try and use Synology's admin credentials, it just works. No way to access the share with domain user credentials.

I also tried to configure a new network place, no success. SMB3 is activated at the Synology.


Any ideas?




#2 Gavin Chappell

Gavin Chappell
  • Moderators
  • 402 posts
  • LocationNottingham, UK

Posted 02 July 2018 - 07:50 AM

What version of the Firewall firmware are you running? SMB2/3 support is a relatively recent addition and has been primarily tested against real Windows servers, and Samba on Ubuntu 16.04LTS. I'm not aware of anything that would cause it not to work against a Synology NAS (which probably also uses Samba) but we cannot exhaustively test NAS boxes from every vendor.

#3 JeWe

  • Members
  • 96 posts
  • LocationGermany, NDS

Posted 12 July 2018 - 04:48 AM

Sorry for the late reply, didn't get a mail that there is an answer.


We are using 7.1.3-061.


Some additional info: I made it establishing a working solution. Before, it was OK to fill in the user name like this: domainuser. Before, it only works if I fill in FQDN_of_our_domain\domainuser.

At Synology site, all SMB1 to SMB3 are allowed.

#4 JeWe

  • Members
  • 96 posts
  • LocationGermany, NDS

Posted 13 September 2018 - 07:29 AM

Somewhat late, but maybe this helps others: Was a bug, the firewall didn't handle the session name correctly. Works now with 7.2.2-057