I'm reporting the bug that was reported here: https://bugzilla.redhat.com/show_bug.cgi?id=910735 The problem occurs in 4.0.2 and 4.0.3 but not in 4.0.1 The problem is that "force user" does not seem to be working. Details, as from the mentioned bug report: Install samba 4.0.2 Edit smb.conf I changed: # diff smb.conf-orig smb.conf 89c89 < workgroup = MYGROUP --- > workgroup = UNE 110c110,112 < max log size = 50 --- > max log size = 500 > log level = 3 passdb:5 auth:10 winbind:2 > 123,124c125,126 < security = user < passdb backend = tdbsam --- > ; security = user > ; passdb backend = tdbsam 147c149 < ; security = domain --- > security = domain 235a238 > wins server = 129.180.3.55 320a324,332 > > [testshare] > path = /home/testshare > read only = no > browseable = yes > volume = Test Share > force user = testuser > valid users = ngaywood > net rpc join -U user@ad.domain systemctl enable smb.service nmb.service systemctl start smb.service nmb.service I then tried to connect to smb://servername/testshare and was prompted for username/domain/password put in the details for ngaywood and the connection failed. I then downgraded the samba: yum downgrade libsmbclient-4.0.1-1.fc18.x86_64.rpm libwbclient-4.0.1-1.fc18.x86_64.rpm samba-4.0.1-1.fc18.x86_64.rpm samba-client-4.0.1-1.fc18.x86_64.rpm samba-common-4.0.1-1.fc18.x86_64.rpm samba-libs-4.0.1-1.fc18.x86_64.rpm Tried to connect to smb://servername/testshare, entered details for ngaywood and connected. Could place files in testshare as ngaywood. The files written as user testuser.
The bug occurred in the Fedora RPM going from 4.0.1 to 4.0.2 In the official samba update from 4.0.1 to 4.0.2, the only updates in there were to SWAT and nothing to do with force user. However, the fedora update from 4.0.1 to 4.0.2 also contained the patch: "Fix conn->share_access which is reset between user switches." which is the patch for the bug #9518 that later went into 4.0.3
Hmmm. Isn't there a conflict here ? You're saying: force user = testuser and then: valid users = ngaywood which means that the user you're trying to force isn't valid on the connect. Does this set of options even make any sense ? Jeremy.
(In reply to comment #2) > Hmmm. Isn't there a conflict here ? > > You're saying: > > force user = testuser > > and then: > > valid users = ngaywood > > which means that the user you're trying to force isn't valid on the connect. > > Does this set of options even make any sense ? I always used to think of "valid users" being the list of users that could authenticate themselves to use that share, and "force user" being the one that would own the files on the disk, so it never seemed strange to me. It did work until 4.0.2 that way. I've tried adding the "force user" account to the list of "valid users" and that has resolved the problem for me. Perhaps this used to happen implicitly?
Hmmm. So it's a change in behaviour, but in this case I think your workaround is the best solution rather than making a code change. Can we close this one with the smb.conf change as the workaround ? Jeremy.
I'm happy with the change of behaviour. I fixed my configuration file and it's all working fine with samba 4.0.3 I was with Paul on this one. I've been using this configuration for years and never really thought of the "force user" as a real user. The username was simply a name I could label various shares by. It had always been a locked account with no accessible password.
No, the 'forced' user has always been a real user. Ok, closing this one out as resolved. Thanks ! Jeremy.