I have a samba server on F-18 and a Windows XP guess running via libvirt/qemu on the same machine that I access host files on using the same server. In order to share files between a couple of users, I have always used "force user" and "force group" on the appropriate shares, which worked fine up until last night when I last successfully used it. This morning I updated to samba 4.0.3 and I was unable to connect to any of the shares using "force user", though I was able to connect to my home directory. When attempting to connect to the "force user" shares, I was prompted for username and password but was unable to authenticate. smbstatus reported that I had a connection as the expected username ("paul"). I tried using "yum downgrade" to revert samba to the previous version but got version 4.0.2, which also didn't work, though my yum.log suggests that I had 4.0.1 between 30th January and last night. I might try pulling that from koji and trying that later, but I haven't done that yet. I'm using security = user and one of the affected shares looks like this: [SoftLib] comment = Software Library path = /srv/softlib valid users = paul bingning public = no writeable = yes printable = no force user = softlib force group = softlib After some experimentation, I found that this configuration, not using "force user" allowed me to connect: [SoftLib] comment = Software Library path = /srv/softlib valid users = paul bingning public = no writeable = yes printable = no ; force user = softlib force group = softlib force create mode = 0664 force directory mode = 2775 By making all of the files on that share group-writable and adding "paul" and "bingning" to the "softlib" group, I've got basically the same functionality, but I'd like to go back to the original configuration and use it on other shares as I don't want to touch all files on my server to tweak permissions really. Any thoughts on what might be wrong and how to debug it?
I have this same problem with samba-4.0.2-1.fc18.x86_64 After downgrading back to samba-4.0.1-1.fc18.x86_64 my "force user" shares started working again. I did not try 4.0.3
4.0.2 was security release, as well as 4.0.1, and both did not touch this part of the smbd. We need to look what additional patches were in 4.0.2-1 package compared to 4.0.1-1. This rules out any changes from upstream except, possibly, https://bugzilla.samba.org/show_bug.cgi?id=9518
I've been able to reproduce this with a minimal configuration. 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 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.
I've reported this upstream https://bugzilla.samba.org/show_bug.cgi?id=9661
So from the upstream bug report, this is simply a change of behaviour. To fix the problem you need to edit your smb.conf file and add the 'force user' username to the list of valid users for the share. All working fine for me with samba-4.0.3-2.fc18.x86_64 and the configuration changes.
Are you fine if we close this as NOTABUG?
Yes, the workaround of adding the "force user" username to the list of "valid users" works for me.