SMB SR Creation Fails

gskger

I have the same result (fail) on a synology share. Accessing the share from W10 works with the path, user and password.

sr.createSmb
{
  "host": "aa4b3c41-a5dc-48ea-94f9-1a6b395d22f7",
  "nameLabel": "myplaylab-smb",
  "nameDescription": "myplaylab-smb",
  "server": "\\\\10.10.20.150\\myplaylab-smb",
  "user": "xcpsmb",
  "password": "* obfuscated *"
}
{
  "code": "SR_BACKEND_FAILURE_111",
  "params": [
    "",
    "SMB mount error [opterr=mount failed with return code 32]",
    ""
  ],
  "call": {
    "method": "SR.create",
    "params": [
      "OpaqueRef:f8b6d893-338d-40e4-9e4a-c978a3ee9f24",
      {
        "server": "\\\\e20150\\myplaylab-smb",
        "user": "xcpsmb",
        "password": "* obfuscated *"
      },
      0,
      "myplaylab-smb",
      "myplaylab-smb",
      "smb",
      "user",
      true,
      {}
    ]
  },
  "message": "SR_BACKEND_FAILURE_111(, SMB mount error [opterr=mount failed with return code 32], )",
  "name": "XapiError",
  "stack": "XapiError: SR_BACKEND_FAILURE_111(, SMB mount error [opterr=mount failed with return code 32], )
    at Function.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at file:///opt/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:35:21
    at runNextTicks (node:internal/process/task_queues:60:5)
    at processImmediate (node:internal/timers:447:9)
    at process.callbackTrampoline (node:internal/async_hooks:128:17)"
}

Message from /var/log/SMlog

Feb  6 21:29:06 e20110 SM: [31263] NOTE: No CIFS credentials found in dconf
Feb  6 21:29:06 e20110 SM: [31263] ['mount.cifs', '\\\\10.10.20.150\\myplaylab-smb', '/var/run/sr-mount/SMB/10.10.20.150/myplaylab-smb/55b4a94a-f6c9-8003-1f26-a2206201e9b6', '-o', 'cache=loose,vers=3.0,actimeo=0,guest']
Feb  6 21:29:06 e20110 SM: [31263] FAILED in util.pread: (rc 32) stdout: '', stderr: 'mount error(13): Permission denied
Feb  6 21:29:06 e20110 SM: [31263] Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Feb  6 21:29:06 e20110 SM: [31263] '
Feb  6 21:29:07 e20110 SM: [31263] ['mount.cifs', '\\\\10.10.20.150\\myplaylab-smb', '/var/run/sr-mount/SMB/10.10.20.150/myplaylab-smb/55b4a94a-f6c9-8003-1f26-a2206201e9b6', '-o', 'cache=loose,vers=3.0,actimeo=0,guest']
Feb  6 21:29:07 e20110 SM: [31263] FAILED in util.pread: (rc 32) stdout: '', stderr: 'mount error(13): Permission denied
Feb  6 21:29:07 e20110 SM: [31263] Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Feb  6 21:29:07 e20110 SM: [31263] '
Feb  6 21:29:07 e20110 SM: [31263] Raising exception [111, SMB mount error [opterr=mount failed with return code 32]]
Feb  6 21:29:07 e20110 SM: [31263] lock: released /var/lock/sm/55b4a94a-f6c9-8003-1f26-a2206201e9b6/sr
Feb  6 21:29:07 e20110 SM: [31263] ***** generic exception: sr_create: EXCEPTION <class 'SR.SROSError'>, SMB mount error [opterr=mount failed with return code 32]
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Feb  6 21:29:07 e20110 SM: [31263]     return self._run_locked(sr)
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Feb  6 21:29:07 e20110 SM: [31263]     rv = self._run(sr, target)
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 323, in _run
Feb  6 21:29:07 e20110 SM: [31263]     return sr.create(self.params['sr_uuid'], long(self.params['args'][0]))
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SMBSR", line 247, in create
Feb  6 21:29:07 e20110 SM: [31263]     raise xs_errors.XenError('SMBMount', opterr=exc.errstr)
Feb  6 21:29:07 e20110 SM: [31263]
Feb  6 21:29:07 e20110 SM: [31263] ***** SMB VHD: EXCEPTION <class 'SR.SROSError'>, SMB mount error [opterr=mount failed with return code 32]
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 378, in run
Feb  6 21:29:07 e20110 SM: [31263]     ret = cmd.run(sr)
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Feb  6 21:29:07 e20110 SM: [31263]     return self._run_locked(sr)
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Feb  6 21:29:07 e20110 SM: [31263]     rv = self._run(sr, target)
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SRCommand.py", line 323, in _run
Feb  6 21:29:07 e20110 SM: [31263]     return sr.create(self.params['sr_uuid'], long(self.params['args'][0]))
Feb  6 21:29:07 e20110 SM: [31263]   File "/opt/xensource/sm/SMBSR", line 247, in create
Feb  6 21:29:07 e20110 SM: [31263]     raise xs_errors.XenError('SMBMount', opterr=exc.errstr)
Feb  6 21:29:07 e20110 SM: [31263]

Mounting on the command line works with

mount -t cifs --verbose '//10.10.20.150/myplaylab-smb' /mnt/smb -o 'username=xcpsmb,password=* obfuscated *'

Manually creating files and directories works on the mounted share (on the host, XO from source commit 2498a and the W10 client).

Edit: add output from /var/log/SMlog, comment on creating files and directories and XO from source commit

Tristis Oris

i have same ticket opened. https://github.com/vatesfr/xen-orchestra/issues/7356

TristisOris created this issue in vatesfr/xen-orchestra

closed SMB VDI share mount error - extra backslash on creation #7356

gskger

@Tristis-Oris Great, thank you

DustinB

I had a similar experience not to long ago, though NFS on Synology for an existing directory that was previously connected to a recently rebuilt host.

We didn't get to far along on that, to fix the issue I made a new share on the synology, moved everything over and then connected the new share to XO without much fanfair.

gskger

@DustinB Yep, I am using NFS on Synology as well for ISO repository, storage repository (SR) and backup repository (BR). Also using a TrueNAS CORE host for NFS shares in my playlab. Both work great.

gb.123

@gskger @Tristis-Oris @MathieuRA @olivierlambert
Can anyone tell me the difference between creating an SMB SR at Pool level vs at Host level ?

Somehow XO does not allow storage to be created at 'Pool' level but through Xen Center, I am able to create an SMB SR at 'Pool' Level.

Will creating SR at pool level interfere with XO later (since this is not allowed by XO)?
Or is it simply a missing GUI in XO ?

olivierlambert

It doesn't matter, it's the exact same thing. Any NFS/SMB/iSCSI SR will be shared by all the pool members anyway.

gb.123

@olivierlambert

Hmm.. In that case, should we change the GUI in XO to create it at Pool level only for cleaner interface (hide host lists) ?

Also, it will be a little more clearer that it would be shared.

(I mean this can be done in XO-6, since this is not a critical feature (though a good to have feature))

olivierlambert

That's correct, we'll try to think it better for XO 6, even if there's no universal "better", it depends on many things (like maybe starting to select shared or not, but this might introduce complexity: we'll discuss that with @clemencebx )

gb.123

@olivierlambert said in SMB SR Creation Fails:

(like maybe starting to select shared or not, but this might introduce complexity: we'll discuss that with @clemencebx )

Rather than selecting shared or not, we can simply have level of creation... eg. if created at pool level, it is shared, if at node level, then only connected to node.

That should help reduce complexity in UI.

olivierlambert

There's many choices, so we'll see when discussing with @clemencebx

MathieuRA

Hi!

The issue should be resolved on the branch fix-smb-storage