1

I am trying to share a folder using the GUI (nemo) or the command line like 

net usershare add temp /home/administrator/tmp comment Everyone:R guest_ok=y

In both cases I get the error message 

net usershare add: cannot convert name "Everyone" to a SID. The network responded incorrectly.

I found a lot of threads with similar issues, but slightly different messages, like 

'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. The connection was refused.

or 

'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. Invalid parameter.

and tried the solutions mentioned there but nothing seems to solve it.

My relevant section in the smb.conf is

usershare max shares = 100
usershare allow guests = yes
usershare owner only = no
username map = /etc/samba/smbusers
encrypt passwords = yes
guest ok = yes
guest account = nobody

I have a user nobody

cat /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

and it has a samba password

sudo smbpasswd -a nobody

Similar commands 

net usershare add temp /home/administrator/tmp bla nobody:F guest_ok=y
net usershare add temp /home/administrator/tmp bla nobody:F guest_ok=n

show the same error message.

I have some entries in /var/lib/samba/usershares, but can't remember how they got there, but the shares are not available.

One examples is

#VERSION 2
path=/home/administrator/Downloads/
comment=Everyone:R
usershare_acl=S-1-1-0:R
guest_ok=n
sharename=Downloads

Any idea what am I might be missing?

Joe
  • 113
  • 1
  • 1
  • 5

2 Answers2

1

I have an alternative in case you are interested. If you originally set the server min to SMB2 because of the SMB1 security issue set the client max to SMB3:

server min protocol = SMB2
client max protocol = SMB3

Then your usershare add command will not result in an error.

You will of course disable browsing to shares as I explained here: How to tell Gigolo / GVFS to use SMBv2 for Windows shares?

Morbius1
  • 7,261
  • 1
  • 15
  • 22
0

At the moment the only way I can reproduce that error is by changing the minimum server protocol from LANMAN1 to SMB2 ( or SMB3 ) in smb.conf. Do you have this line in your smb.conf:

server min protocol = SMB2

Or maybe it somehow got changed in the default. To find out:

testparm -sv | grep protocol
Morbius1
  • 7,261
  • 1
  • 15
  • 22
  • Yes, I just found that this might be related. I tried manually accessing the Samba share using "smbclient -L 192.168.2.103 -W WORKGROUP". That finally gave a useful error message: protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE. – Joe Dec 10 '17 at 19:15
  • So, yes I had "server min protocol = SMB2" in the smb.conf, I added an entry "protocol = SMB3" not, it still does not work. Maybe I need to restart, instead of restarting the service... – Joe Dec 10 '17 at 19:16
  • A restart won't do you any good. I think it's fair to say this is a bug in usershare. The creation of a samba share shouldn't be dependant on the default setting of LANMAN1 as the minimum server dialect. – Morbius1 Dec 10 '17 at 19:30
  • I changed my settings to `server min protocol = NT1` and `server max protocol = SMB2` as mentioned [here](https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0127394) . Now it works. Not sure why it did not work, the page mentiones something about SMB2 not being supported in the kernel. – Joe Dec 10 '17 at 19:33
  • That should work although I wouldn't degrade the max protocol. The default is SMB3 which is where Windows and MacOS are these days. – Morbius1 Dec 10 '17 at 19:39