Unfortunately I haven’t been able to figure out yet how to share specific directories only, so I set up my Samba server to share users’ home directories (which is not a security issue here since the only possible client is my other machine). My user’s home directory contains a symlinked directory on another hard drive partition, which I had to explicitly share to be able to access it from the other machine. This setup has been working for months now, but for a reason that escapes me at the moment it stopped working today, presumably after samba got updated from 3.4.2-1.1.3.1 to 3.4.3-3.2.1.
The error message on the client (Windows XP/SP3) for this one above mentioned directory, and for this directory alone, is “Access denied”; I can access all other directories fine.
Any hints to what I can do to make this work again will be greatly appreciated.
Ok, problem not solved but worked around: I wasn’t aware that I could access this explicitly shared directory directly, i.e. not via the symlink in my /home. So I have my access back, but the problem remains to be addressed.
i think what might be the best place on the web for you is: http://www.swerdna.net.au/linux.html
upper left hand corner is Samba help that i think even i might
understand…
>
> Ok, problem not solved but worked around: I wasn’t aware that I could
> access this explicitly shared directory directly, i.e. not via the
> symlink in my /home. So I have my access back, but the problem remains
> to be addressed.
>
>
vzduch;
There was a serious security problem with the “wide links” parameter in
smb.conf. It was possible for a user to gain arbitrary access to
directories. To correct this the default value for wide links was changed
from yes to no. The most recent Samba releases incorporated this change. I
don’t think this applied to 4.3, however it may have been incorporated by
Opensuse in it’s release. You can check this by executing:
testparm -v | grep "wide links"
If wide links is set to No you can add this parameter to the global section
of /etc/samba/smb.conf to recover the previous behavior.
wide links = Yes
After making this change you will need to restart smbd.
Be aware however that you might be creating a security problem by setting this
to yes.
See: man smb.conf to see the use of the wide links parameter.
–
P. V.
“We’re all in this together, I’m pulling for you.” Red Green
> On Wed March 24 2010 01:36 pm, vzduch wrote:
>
>>
>> Ok, problem not solved but worked around: I wasn’t aware that I could
>> access this explicitly shared directory directly, i.e. not via the
>> symlink in my /home. So I have my access back, but the problem remains
>> to be addressed.
>>
>>
> vzduch;
>
> There was a serious security problem with the “wide links” parameter in
> smb.conf. It was possible for a user to gain arbitrary access to
> directories. To correct this the default value for wide links was changed
> from yes to no. The most recent Samba releases incorporated this change. I
> don’t think this applied to 4.3, however it may have been incorporated by
> Opensuse in it’s release. You can check this by executing:
>
venzkep: Thanks for the explanation. “Wide links” was indeed set to “No” (though I don’t know what it was set to before), so I added the suggested line to the global section of smb.conf. I’ll see the result next time I fire up my other machine.
And as long as no one can penetrate my firewall with a Samba connection, security shouldn’t be an issue since the only person who has access to my LAN is me.
Experienced same problem since earlier this week.
Tried above suggestion this morning, and “wide links” are now “yes”, but still can no longer log in to windows workgroup to access other workstations on peer-to-peer network, as authentication fails.
Rolling back samba update seems to be an alternative.
>
> Experienced same problem since earlier this week.
> Tried above suggestion this morning, and “wide links” are now “yes”,
> but still can no longer log in to windows workgroup to access other
> workstations on peer-to-peer network, as authentication fails.
> Rolling back samba update seems to be an alternative.
>
>
ncalder;
The “wide links” parameter only effects the clients ability to follow sym
links on the Linux server, it should have no effect connecting to Windows
shares. There may have been some other changes that are causing the behavior
you observe.
P. V.
“We’re all in this together, I’m pulling for you.” Red Green
I also had the same problem with Samba not working after updating from 3.4.2-1.1.3.1 to 3.4.3-3.2.1. The newer version is from opensuse update while the version that works is from opensuse OSS.
What I saw was a problem of the Samba Client to view a Workgroup even as the Samba Server still worked to allow other PC’s to connect to my Linux machine.
No matter how well intended an update might be, if it kills the patient it is no good in my mind, so I dropped back to the OSS repo version 3.4.2-1.1.3.1 and all is well with my world again.
Thanks PV and James and, on the other thread, FarcusNZ:
Roll back to
samba-3.4.3-3.2.1
samba-client-3.4.3-3.2.1
cifs-mount-3.4.3-3.2.1
libsmbclient0-3.4.3-3.2.1
libwbclient0-3.4.3-3.2.1
libtalloc1-3.4.3-3.2.1
libtdb1-3.4.3-3.2.1
did the trick nicely - windows workgroup and shares are again visible.