Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
An issue with our samba file server here at work was brought to my attention yesterday. When a file is copied/moved over to the server the date of the file is changed to the current date and time that the file is copied over. It does not seem to matter whether you are replacing a file or not.
What I am trying to get at is this: If I have a file on my workstation that is say 2 days old and I copy/move it over to the server, the date is changed to today. If I do this same action from a Windows machine to a windows machine, the date remains as its original date, 2 days ago.
Is it possible to not have the date modified when a file is copied/moved over to the samba server? This is important as a number of our draftspeople do work locally on thier own machines and then copy/move their files over to the server when they are done.
I have search this and other forums for a solution and found none, although the question has been asked but received no responses. I have read the man pages but found nothing that address this issue. I have also googled this problem to death and found very little.
I know that when you are copying/moving files locally on a linux machine you can use flags to control this and I am hoping there is a setting or parameter I can add to get this same type of functionality.
I thank you for any assistance
P.S. if it is not possible to get around this then please let me know. Thanks
Last edited by mdkelly069; 11-27-2003 at 10:27 AM.
The only thing I could find that might work at all for you is from man smb.conf:
dos filetimes (S)
Under DOS and Windows, if a user can write to a file they can change the timestamp on it. Under POSIX semantics, only the owner of the file or root may change the timestamp. By default, Samba runs with POSIX semantics and refuses to change the timestamp on a file if the user smbd is acting on behalf of is not the file owner. Setting this option to yes allows DOS semantics and smbd will change the file timestamp as DOS requires.
Default: dos filetimes = no
If that doesn't do it, I don't see anything else that will do what you want ...
All files and folders on the server are owned by the 'komex' group. The drive it is running off of is formatted FAT32 until the higher ups in the IT department become more comfortable with Linux and all the great things it can do for our office.
I did notice the dos filetimes parameter you mentioned, but I was not sure it would do what I was looking for either. I will try t out tonight.
Could the fact the drive is FAT32 be causing some of the problem?
When is the user smbd acting on the file? Is it when a user other than the owner is working with the file?
Sorry for the extra questions but I am still a bit new to the Samba idea. I understand the basics of the system, but am still working on the nitty gritty.
Pardon me: all files are owned by root and are part of the komex group. I am thinking this is not the way that it should be, but I am not sure why it is this way. As I mentioned before the only thing diffeent about this setup is that it is running off of a FAT32 drive that is mounted in fstab at boot time.
Last edited by mdkelly069; 11-27-2003 at 03:51 PM.
You have linux doing file shares from a FAT32 drive to a windows network? Oh. That's tricky. Samba largely is a mapping from Unix to Windows and back (hence all the map opetions). Mounting a Windows drive in Linux would certainly add a layer of complexity since FAT32 doesn't have file permissions and that's likely the obstacle. If at all possible, you should try to move your Samba shares off the FAT partition.
As for when the samba user acts on the file system, it should be rarely if ever. Unless a valid user is provided, files will be owned by the user and group 'nobody' by default. If file permissions are an issue then you should probably create an approriate user and make use of the 'force user = <user>' option.
I hope things are going well for you. Don't forget to read up on chown and chmod. They're your friends.
archangel_617b: Thank you for the reply and the information.
Linux shares off of a FAT32 drive is not by my choice. We used to run a Win2000 file server but after hiring new employees we ran up against the 10 user connection limit. After a couple of weeks of everyone being not happy I suggested we move to a Linux/Samba based solution. The higher ups agreed, but did not totally trust Linux so they required me to run the shares off a FAT32 drive so it could be swapped back to a windows machine on a moments notice.
I think/hope this will be enough to get them to let me move to a Linux native file system. After all the system has been up and running without a hicup for over a month now and I get nothing but compliments for the work.
I definately need to learn more about chown and chmod. I ran up against them last night while I was trying to set up vsftpd at home and was having to type commands I really did not understand.
Thanks again and I will post a follow up when I have converted the drive over.
Congrats. It sounds like you're doing good with the Linux conversion.
In addition to chown and chmod, at some point you may find the schduling facilities, "cron" and "at", very helpful for maintaining your system. I use cron to apply the appropriate permissions to the shared file systems in case something or someone left a file too restrictive (or too public).