External storage / SMB share redux

New 10.0.10 deployment - want to add an SMB share

settings

I have the “green” spot on the left that would presumably imply that my settings are validated but that would be probably too much to expect… When the user try to access the folder they get an error message (temporarily unavailable).

My questions:

  1. Is there some built in tool allowing to actually test the settings entered (short of trial & error) ?
  2. What is the intended meaning of the green dot ?
  3. What syntax should be used for
    3.1 Domain (domain, domain.local, something else ?)
    3.2 Share name (SharedFolder, /SharedFolder, something else ?)
    3.3 Subfolder (Subfolder, /Subfolder, something else ?)
  4. Any specific string I should grep in the logs

Any help / pointer welcome

Green dot means connection can be established.

you rarely need the domain field.

Share name should be the name of the share without any extra characters. You can check the share name on your server. There is probably something like \AD\Share1. You only need the share1 part because the app, external storage, puts host+share name and looks this up.

Subfolder is only needed if you have a parent share which is accessible by everyone, and a subfolder that you want only the user to have access to.

I would keep it simple, fill out the host, share, user and password fields and try to access it.

Thanks for your reply… unfortunately I can’t seem to make it work

Green dot means connection can be established.

As in ping ? does it check for the share name ? valid credentials ? It would be very useful (but heck this is only v10…)

I would keep it simple, fill out the host, share, user and password fields and try to access it

Tried that and ratchet up with documenting the domain (in various forms) etc - nothing works.

Next step was to dig into the logs. All I can pinpoint are these errors

{"reqId":"VIWNlgRN5B7MhutgFQvr","level":3,"time":"2018-11-29T23:38:35+00:00","remoteAddr":"212.147.*.*","user":"user","app":"files_external","method":"GET","url":"\/index.php\/apps\/files_external\/userglobalstorages\/1?testOnly=false","message":"Exception: {\"Exception\":\"OCP\\\\Files\\\\StorageNotAvailableException\",\"Message\":\"Unknown error (NT_STATUS_OBJECT_NAME_INVALID) for \\\/\",\"Code\":0,\"Trace\":\"#0 \\\/opt\\\/bitnami\\\/apps\\\/owncloud\\\/htdocs\\\/lib\\\/private\\\/Files\\\/Storage\\\/Common.php(440):

using invalid credentials results in

{"reqId":"xkOOJQeMjRdme0EdMvs7","level":3,"time":"2018-11-29T23:38:06+00:00","remoteAddr":"212.147.*.*","user":"user","app":"files_external","method":"GET","url":"\/index.php\/apps\/files_external\/userglobalstorages\/1?testOnly=false","message":"Exception: {\"Exception\":\"OCP\\\\Files\\\\StorageNotAvailableException\",\"Message\":\"Invalid login\",\"Code\":0,\"Trace\":\"#0

so I guess there is some handshake going on between OC and the windows box…

Furthermore this works

bitnami@debian:~$ /usr/bin/smbclient -d 4  -U myDomain\\administrator \\\\172.16.50.202\\SharedFolder02
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
doing parameter workgroup = WORKGROUP
doing parameter dns proxy = no
doing parameter log file = /var/log/samba/log.%m
doing parameter max log size = 1000
doing parameter syslog = 0
WARNING: The "syslog" option is deprecated
doing parameter panic action = /usr/share/samba/panic-action %d
doing parameter server role = standalone server
doing parameter passdb backend = tdbsam
doing parameter obey pam restrictions = yes
doing parameter unix password sync = yes
doing parameter passwd program = /usr/bin/passwd %u
doing parameter passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
doing parameter pam password change = yes
doing parameter map to guest = bad user
doing parameter usershare allow guests = yes
pm_process() returned Yes
added interface ens32 ip=172.16.50.210 bcast=172.16.50.255 netmask=255.255.255.0
Client started (version 4.5.12-Debian).
Enter myDomain\administrator's password:
Connecting to 172.16.50.202 at port 445
 session request ok
Doing spnego session setup (blob length=120)
got OID=1.3.6.1.4.1.311.2.2.30
got OID=1.2.840.48018.1.2.2
got OID=1.2.840.113554.1.2.2
got OID=1.2.840.113554.1.2.2.3
got OID=1.3.6.1.4.1.311.2.2.10
got principal=not_defined_in_RFC4178@please_ignore
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Got challenge flags:
Got NTLMSSP neg_flags=0x62898215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_TARGET_TYPE_DOMAIN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_TARGET_INFO
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
Domain=[myDomain] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]
 session setup ok
 tconx ok
smb: \>

How should I “translate” it into OC settings ?

I am starting to wonder… is this actually working at all ? Anyone here able to mount a Windows Server 2012R2 share with OC 10.0.10 ?

I have spent countless hours trying anything I can come up with to no avail. The debian server I am running OC on can connect without issue, so it is clearly somehow a problem with OC. Before I commit more time to this I’d really love to hear from anyone who had managed this…

Why are you using Win Server 2012 in the year 2018? Win Server 2016 would be my choice.

Agreed - existing infra I’m afraid.

Still my question remains: anyone running OC 10.0.10 with external SMB mount from server 2012R2 ?

23

1 Like

Thanks for confirming that it is indeed possible :slight_smile:

Do you know what the “green dot” is actually testing (I get it, but still get an error when trying to access the share). Connectivity ? Credentials ? Share existence ? Able to browse said share ?

My guess would be - permissions.

Check that in the “sharing” section on the win 2012 server you have the user and full control configured. Then in the security section you also have to make sure the user has the rights.

After that there is not much you can do wrong.

Maybe there is also a difference between using smbclient vs. php-libsmbclient (have read from both in the past)?

Thanks for your input.

  1. I can connect from the system hosting OC via smbclient - good point about php-libsmbclient having possibly different requirements. In any case that is pretty much taking care of the credentials / rights issue. BTW similar output with AD or local user.
  2. I can see that the “green dot” even if I use bogus credentials - so I guess there isn’t much tested here (at the very least room for improvement).
  3. Looking into the logs I definitely see different output with correct and incorrect credentials. With the later I have the NT_STATUS_OBJECT_NAME_INVALID error… tried to google it to little success so far.

SOLVED!!! Well sought of. There is definitely something off with the OC 10.0.10 code with SMB. As a test I setup a NextCloud (v15) server and it works flawlessly with SMB including getting a red light when you put in bogus credentials. Besides the initial message of incompatibility we will be sticking with nextcloud in the backend of our OC clients until OC server fixes this problem.

Hey,

if you think this is a bug in the oC server then i would report this to a bug tracker like https://github.com/owncloud/core/issues

From my experiences with user support forums like the one here is that reported bugs/issues are mostly staying unfixed as they often gets missed in between all other support topics. :slightly_frowning_face: