Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
Write an article for LinuxForums Today! Win Great Prizes!
Right now windowsXP can read files over the network from /shared on samba. But it isn't able to write anything.
1) I've been reading the documentation on samba's website, but I'm stuck. I cannot write to the shared directory from windowsXP. What's wrong?
I want a directory that is writable for guests(so it doesn't require a user account on the samba computer), but they can only read or write to that directory.
I created a directory /shared. At first I chmodded it to 755. Then when I wanted to allow the windowsXP client to be able to write, I chmodded it to 777, and set writable = true, which didn't work. So I tried read only = no, which also didn't work.
2) Should the user and group of /shared be set to root?
3) Does it matter if the shared directory is in root, (/shared), or should it be in something like /home/samba/shared or /home/shared/ or /usr/samba/share ?
Root is the owner of the shared resource; therefore, allowing only root to read/write to the share. Try downloading Webmin and configure your Samba server using the Webmin. Trust me, it will save you a lot of headaches. Then, once you create shares, you can Force Unix user to the actual owner of the share - providing your Windows clients read/write access.
Anyway, the way you've got it now, the only account that can write to this share is the Root user.
Root is the owner of the shared resource; therefore, allowing only root to read/write to the share. Try downloading Webmin and configure your Samba server using the Webmin. Trust me, it will save you a lot of headaches. Then, once you create shares, you can Force Unix user to the actual owner of the share - providing your Windows clients read/write access.
It came with SWAT, but I need to know what permissions are correct, or what I'm doing wrong. After I figure this out I am going to check out the GUI.
Quote:
Anyway, the way you've got it now, the only account that can write to this share is the Root user.
Right now in any user account I can write to /shared. I can't write to it through network neighborhood on windows.(ie: through samba)
1) Are you saying samba will not allow write access on guest unless the guest account has group(or user?) permissions on the file? (I think samba uses nobody)
2) I think you're telling me to use security = user. Which from what I understand will require an account for each person that wants to read or write to /shared. I used security = share because I want users to be able to login as guest, but be able to read and write to /shared.
I'm currently running 15-Samba servers in my data center and I always employ user level authentication as compared to share. And yes, to the best of my knowledge, Samba defaults Share level access to the "nobody" account. What you may need to do is configure your nobody account to read/write instead of root.
The simplest way to configure Samba shares is to create the shares using a non-root account. This minimizes your security considerations when trying to configure directory permissions. The creator of a directory is the owner.
Your global permissions are currently granting read/write and execute; however, your user and group owners are set to root; therefore, I believe that this is the problem. Change your ownership to another user account and grant 777 access and you will be good to go.
Prior to doing this, download and install Webmin and once loaded, click on Servers and Windows File Server and check your configurations there. Create a share with a non-root account and force Unix user to use this account and you will have read/write access.
Again, I don't use share level access due to security considerations - I only use user level and I integrate my authentication with Active Directory so I am rather unskilled in creating wide open shares with Linux.
Open Source Security Myths Dispelled Dispel the five major myths surrounding Open Source Security and gain the tools necessary to make a truly informed decision for your IT organization subscribe
InformationWeek InformationWeek is the only newsweekly you'll need to stay on top of the latest developments in information technology. subscribe