Access denied on samba share created with net usershare [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
When creating a samba shared folder using net usershare command, I can't login to it via Dolphin or other file browsers. I get as far as an authentication dialog, but not matter what credentials I use, I get the dialog again and again, until I escape, which then gives me an 'Access denied to smb://uname@location/shareFolder.'
I'm using Linux Mint 18.2. The usershare generated by the usershare add command generates:
[ShareName]
path=/home/user/ShareFolder
comment=
usershare_acl=Everyone:D,DOMAINuser:F,
guest_ok=n
My smb.conf is pretty vanilla:
[global]
workgroup = WORKGROUP
netbios name = NETNAME
usershare path = /var/lib/samba/usershares
usershare max shares = 100
log file = /var/log/samba/%m
log level = 1
If it's telling at all, when I run smbclient -U, I get:
sudo smbclient -U user //hostname/sharefolder
Enter user's password:
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
This is not the behaviour at all when share are set directly in smb.conf. The usernames are all real users on the host, as well as in samba (smbpasswd -a user) and are all enabled (smbpasswd -e user).
samba shared-folders dolphin
asked Sep 26 '17 at 15:00
H Petrus
112
closed as off-topic by Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÃ…Â Katsura Oct 1 '17 at 18:17
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÅ Katsura
add a comment |Â
up vote
0
down vote
favorite
When creating a samba shared folder using net usershare command, I can't login to it via Dolphin or other file browsers. I get as far as an authentication dialog, but not matter what credentials I use, I get the dialog again and again, until I escape, which then gives me an 'Access denied to smb://uname@location/shareFolder.'
I'm using Linux Mint 18.2. The usershare generated by the usershare add command generates:
[ShareName]
path=/home/user/ShareFolder
comment=
usershare_acl=Everyone:D,DOMAINuser:F,
guest_ok=n
My smb.conf is pretty vanilla:
[global]
workgroup = WORKGROUP
netbios name = NETNAME
usershare path = /var/lib/samba/usershares
usershare max shares = 100
log file = /var/log/samba/%m
log level = 1
If it's telling at all, when I run smbclient -U, I get:
sudo smbclient -U user //hostname/sharefolder
Enter user's password:
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
This is not the behaviour at all when share are set directly in smb.conf. The usernames are all real users on the host, as well as in samba (smbpasswd -a user) and are all enabled (smbpasswd -e user).
samba shared-folders dolphin
asked Sep 26 '17 at 15:00
H Petrus
112
closed as off-topic by Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÃ…Â Katsura Oct 1 '17 at 18:17
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÅ Katsura
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
When creating a samba shared folder using net usershare command, I can't login to it via Dolphin or other file browsers. I get as far as an authentication dialog, but not matter what credentials I use, I get the dialog again and again, until I escape, which then gives me an 'Access denied to smb://uname@location/shareFolder.'
I'm using Linux Mint 18.2. The usershare generated by the usershare add command generates:
[ShareName]
path=/home/user/ShareFolder
comment=
usershare_acl=Everyone:D,DOMAINuser:F,
guest_ok=n
My smb.conf is pretty vanilla:
[global]
workgroup = WORKGROUP
netbios name = NETNAME
usershare path = /var/lib/samba/usershares
usershare max shares = 100
log file = /var/log/samba/%m
log level = 1
If it's telling at all, when I run smbclient -U, I get:
sudo smbclient -U user //hostname/sharefolder
Enter user's password:
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
This is not the behaviour at all when share are set directly in smb.conf. The usernames are all real users on the host, as well as in samba (smbpasswd -a user) and are all enabled (smbpasswd -e user).
samba shared-folders dolphin
asked Sep 26 '17 at 15:00
H Petrus
112
When creating a samba shared folder using net usershare command, I can't login to it via Dolphin or other file browsers. I get as far as an authentication dialog, but not matter what credentials I use, I get the dialog again and again, until I escape, which then gives me an 'Access denied to smb://uname@location/shareFolder.'
I'm using Linux Mint 18.2. The usershare generated by the usershare add command generates:
[ShareName]
path=/home/user/ShareFolder
comment=
usershare_acl=Everyone:D,DOMAINuser:F,
guest_ok=n
My smb.conf is pretty vanilla:
[global]
workgroup = WORKGROUP
netbios name = NETNAME
usershare path = /var/lib/samba/usershares
usershare max shares = 100
log file = /var/log/samba/%m
log level = 1
If it's telling at all, when I run smbclient -U, I get:
sudo smbclient -U user //hostname/sharefolder
Enter user's password:
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
This is not the behaviour at all when share are set directly in smb.conf. The usernames are all real users on the host, as well as in samba (smbpasswd -a user) and are all enabled (smbpasswd -e user).
samba shared-folders dolphin
samba shared-folders dolphin
asked Sep 26 '17 at 15:00
H Petrus
112
asked Sep 26 '17 at 15:00
H Petrus
112
edited Sep 27 '17 at 16:14
asked Sep 26 '17 at 15:00
H Petrus
112
asked Sep 26 '17 at 15:00
H Petrus
112
asked Sep 26 '17 at 15:00
H Petrus
112
112
closed as off-topic by Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÃ…Â Katsura Oct 1 '17 at 18:17
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÅ Katsura
closed as off-topic by Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÃ…Â Katsura Oct 1 '17 at 18:17
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, Stephen Rauch, GAD3R, sebasth, SatÅ Katsura
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
Actually, I found the fault in the above USERSHARE tdb entry: it was in the ACL. I had set it nullify the user rights by setting:
usershare_acl=Everyone:D DOMAINuser:F
'Everyone' was set to 'Deny'. 'Everyone' includes, in this case, 'User', as well. So, setting 'User' to 'Full' access - or anything else, for that matter - was overruled by 'Everyone's ACL. The moment I removed 'Everyone' from the equation, everything just worked.
answered Sep 27 '17 at 16:13
H Petrus
112
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Actually, I found the fault in the above USERSHARE tdb entry: it was in the ACL. I had set it nullify the user rights by setting:
usershare_acl=Everyone:D DOMAINuser:F
'Everyone' was set to 'Deny'. 'Everyone' includes, in this case, 'User', as well. So, setting 'User' to 'Full' access - or anything else, for that matter - was overruled by 'Everyone's ACL. The moment I removed 'Everyone' from the equation, everything just worked.
answered Sep 27 '17 at 16:13
H Petrus
112
add a comment |Â
up vote
1
down vote
Actually, I found the fault in the above USERSHARE tdb entry: it was in the ACL. I had set it nullify the user rights by setting:
usershare_acl=Everyone:D DOMAINuser:F
'Everyone' was set to 'Deny'. 'Everyone' includes, in this case, 'User', as well. So, setting 'User' to 'Full' access - or anything else, for that matter - was overruled by 'Everyone's ACL. The moment I removed 'Everyone' from the equation, everything just worked.
answered Sep 27 '17 at 16:13
H Petrus
112
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Actually, I found the fault in the above USERSHARE tdb entry: it was in the ACL. I had set it nullify the user rights by setting:
usershare_acl=Everyone:D DOMAINuser:F
'Everyone' was set to 'Deny'. 'Everyone' includes, in this case, 'User', as well. So, setting 'User' to 'Full' access - or anything else, for that matter - was overruled by 'Everyone's ACL. The moment I removed 'Everyone' from the equation, everything just worked.
answered Sep 27 '17 at 16:13
H Petrus
112
Actually, I found the fault in the above USERSHARE tdb entry: it was in the ACL. I had set it nullify the user rights by setting:
usershare_acl=Everyone:D DOMAINuser:F
'Everyone' was set to 'Deny'. 'Everyone' includes, in this case, 'User', as well. So, setting 'User' to 'Full' access - or anything else, for that matter - was overruled by 'Everyone's ACL. The moment I removed 'Everyone' from the equation, everything just worked.
answered Sep 27 '17 at 16:13
H Petrus
112
answered Sep 27 '17 at 16:13
H Petrus
112
answered Sep 27 '17 at 16:13
H Petrus
112
answered Sep 27 '17 at 16:13
H Petrus
112
112
add a comment |Â
add a comment |Â
