I am new to Linux, and need some help. We have a Linux server running Debian 4.0, that needs to connect to a share on a Windows 2012 Storage Server R2 NAS device.

I've configured the Windows share for NFS, and mounted the share on the Linux server successfully (we tried using cifs, but that doesn't work either...with more issues).
On the Linux server, the mounted directory is set for drwxrwxrwx, but when a user creates/saves a file, the permissions on the file are set as -rw-r--r--.

We are using the following command in /etc/fstab to mount the share:
<ip>:/Data /mnt/Windows nfs rw,_netdev

How do I configure this so that when the Linux user saves a file, the permissions are set to -rw-rw-rw- or -rwxrwxrwx?

Debian 4 (called Etch) is old, I mean really old, and no longer supported( over 4 years since it was last supported). Download and install Debian 7 (called Wheezy) because it is the current Stable release. Once you have that done we can help you through things.
https://en.wikipedia.org/wiki/Debian#History

When a user creates a file anywhere the permissions are likely 664 or 644. You'll need to look into umask to change the default. What happens when a user forces the created file to 777? Does the Windows share change it back or does it persist? If it persists then you just need to change umask. If the Windows share changes it back then you'll need to look into the NFS configuration on the Windows server. Windows file permissions are insanity, and Windows filesystems are no better, so you may have a rocky road ahead of you.

1 members found this post helpful.

Unfortunately, upgrading isn't an option at this time.

How do I use unmask to force that change?

then you have a conundrum
Debian 4 might NOT support the hardware
nor will it have support for the protocols that MS used in win server 2012

https://www.debian.org/releases/etch/

see the problem
windows server 2012 was not even a twinkle in the Microsoft eyes in 2007

install Debian 7

You aren't listening. Upgrading to version 7 is not an option at this time. I would upgrade if I could, but I can't.

I understand the sentiment, but there's a reason protocols and standards are called "protocols and standards" for a reason, it means something. It's the reason why I have a Fedora Core 4 system that can serve and mount NFS shares with a CentOS 7 system without blinking an eye, and why both of which can share and mount Windows XP and Windows 7 shares simultaneously without issue. It's also the reason why the iPod interface I had in my car from 2004 until I sold it in 2012 still worked without issue on an iPhone 4S, a device which hadn't even been imagined at the time the interface was designed circa 2002-2003.

Despite both your and k3lt01's protesting, I do not believe the obsolete status of his OS has anything at all to do with his question.



Now as for the OP - there was an important question in my earlier post. Can a user manually change the permission of his files on the share? If yes, then you simply need to modify the umask to change the default permission for new files. If not, then it's an issue with either the mount or the server (either it's permissions or its filesystem).

You are asking people to support you doing something that is a security risk. When they point that out to you you ignore the advice and then when it is pointed out to you again you are, what many may consider, rude. We are listening but you are asking us to do something that may put other users of your server at risk.

I agree that any machine that's exposed to the outside world in any way should be running an OS that has active security updates, and any machine with a public IP address absolutely MUST be running an OS with active security updates, including having all unnecessary ports shut down, etc. But we have no indication that the machine the OP is referring to falls into either of these categories. For all we know it's a system sitting on a protected LAN, with no external ports being forwarded to it, possibly without any internet access at all. Nothing the OP has asked for is a security risk, no actions we might suggest exposes his machine to intruders, so I don't see the harm in answering his questions. This: "You are asking people to support you doing something that is a security risk." is not true. That's the response for somebody asking how to bypass a firewall, send an ssh password in plain-text, etc. Not the response for somebody asking about a simple network share on an obsolete OS.

Obviously it's always best for everyone if the machine in question is active on its security updates, but that has already been expressed multiple times in multiple different ways. He's got the point, so now let's answer the question.

1 members found this post helpful.

I disagree simply because we do not know about the system so until we do I will assume it is open to the world and therfore is a security risk to anyone who uses it.

Instead of telling me to assist him to do something I have concerns about you could just follow your own advice and post for him how to do what he wants to do, simple isn't it. I trust you and I can leave this discussion here now.

The question is now a moot point. We were able to resolve the permissions issue. For clarity's sake, the server is an internal business only server. It is running a highly customized application that is going to take months to re-write to work on a new version of Linux/PHP. Because of this, upgrading at this time is not an option. Is it something we need to do and plan to do? Yes. But it isn't going to happen in the time frame I needed to get this resolved, so upgrading was not something I could do. I appreciate the input and the hesitation in answering the question.

But I wouldn't have asked the question unless I had no other choice. Upgrading is something that has been worked on for the past 6 months, and probably has 6 more to go before we can do it. Until then, I have to keep this server up and running, ensuring that the business has access to the data it needs. If I don't, I am out of a job. It is that simple. Hence, I came to this site, among others, looking for help.