In helping out a friend with a few questions for CS, I came across one that I had no prior experience with and was hoping someone would be able to clarify the difference between NTFS and File Share for me.
To help, the question we faced was:
A folder storing a faculty member’s personal documents are set as a share to which everyone has full access. The only person with NTFS permissions on the folder is said faculty member. Can everyone else access the documents?
I appreciate any clarification you can provide. I'd love your help in learning about this!
Short answer: No.
In Windows each file and directory has an ACL controlling access to it.
Each file share also has an ACL controlling access to the share.
When you access a remote file through a share you are doing so using the credentials used to login to the local computer. (You can connect using different credentials by entering a username/password when connecting).
The remote computer tests the supplied credentials against the ACL on the share.
Once you are past that, then every file you attempt to access on the remote machine through this connection will be checked using your credentials against the ACL on the file and the share. This allows a file share to offer more restricted access to some files than if the same user were attempt to access them locally. (So you could share files as read-only, even if the ACLs on the files themselves would allow that user write access).
If the file share is of a FAT file system then the only ACL checking that is done is against the file share itself because FAT doesn't support ACLs.
When computer are not in a domain and all user accounts are local user accounts then permissions are maybe not what you expect. Unlike Unix/linux, it is generally not possible to create the same user account (uid) on two computers because Windows basically uses a GUID for the UID (a big random number). So when you attempt to look at file owner or ACL information on remote files, since those files are all owned by local accounts on the remote computer, to your local computer those UID will not be recognized (See dir/q from the command line).
Windows can be setup to make non-domain file sharing a little easier. It can be set so that when you attempt to access the remote file share, as long as the remote computer has an account with the same username and password as the local computer, then the connection is allowed -- and you are logged into the remote computer using the remote computer users account.
For reference, see information on NTLM, SMB and NETBIOS.
Related
After successfully mounting the directory (ZFS remote storage) from one of the server, I'm getting an "Operation not permitted" error when I try changing the ownership of the directory. I'm using the following command:
To mount the remote directory:
mount -t nfs 10.1.32.33:/dir/temp/tools /home/materials
After mounting the directory, the contents are belongs to nobody:nobody
I want to change ownership so I can run the installer inside the directory.
I'm using the command below to change ownership but it's not working:
chown -R otm:otm materials/
I can always upload the file to the server without using the ZFS storage, however I want to start making a central installer repository so I don't need to upload the files/installers for future server install. I appreciate your help guys.
NFS servers by default do not allow root access to files - root is normally mapped to "nobody".
See "root squash":
Root squash[2][3] is a reduction of the access rights for the remote
superuser (root) when using identity authentication (local user is the
same as remote user). It is primarily a feature of NFS but may be
available on other systems as well.
This problem arises when a remote file system is shared by multiple
users. These users belong to one or multiple groups. In Unix, every
file and folder normally has separate permissions (read, write,
execute) for the owner (normally the creator of the file), for the
group to which the owner belongs, and for the "world" (all other
users). This allows restriction of read and write access only to the
authorized users while in general the NFS server must also be
protected by firewall.
A superuser has more rights than an ordinary user, being able to
change the file ownership, set arbitrary permissions, and access all
protected content. Even users that do need to have root access to
individual workstations may not be authorized for the similar actions
on a shared file system. Root squash reduces rights of the remote
root, making one no longer superuser. On UNIX like systems, root
squash option can be turned on and off in /etc/exports file on a
server side.
After implementing the root squash, the authorized superuser performs
restricted actions after logging into an NFS server directly and not
just by mounting the exported NFS folder.
In general, you DO NOT want to disable root squash unless you REALLY know what you're doing as there are serious security issues you can create if you do that. And since you didn't even know it exists...
(And that mention of /etc/exports is an extremely limited statement that is wrong on many systems - like Solaris.)
I have a sql job on SERVER01.
Part of the job is to access a folder located on a different server:
\\SERVER02\Files
I need to be able to create folders and files under it as well as modify/delete files.
The \\SERVER02\Files folder is being shared with several different accounts.
If I go to SERVER02 and try to UNC path to \\SERVER02\Files, it'll ask for a password.
Since the servers are in two different domains, I need to specify the domain for the account:
DOMAIN\accountName
password
Questions:
What is the correct way for me to set this up so that the job will have access to the other server so it can manipulate the files at \\SERVER02\Files ?
This is very confusing so I'm trying to get it right. Any help would be greatly appreciated.
Thanks.
We have this same issue in our own environment, because we have two domains that have to share resources. The technically correct solution is to setup a trust between the two domains so that user logins are mapped across the domains. If you're like us and can't setup a domain trust, you can try some of the following solutions:
Login under the account that the SQL job runs under on SERVER01, and use the Credential Manager to create a login to SERVER02 with the other domain's user / password.
Under the account that SQL job runs, create a network share to the UNC path with the credentials embedded: NET USE M: \\SERVER02\Files [password] /user:[domain\user]. You will have to make sure this path is always mapped before the job runs, and use M: for your path.
If you have a specific process/command you need to run that accesses the network path, you can start that particular process using runas to authenticate with the second domain's credentials: runas /netonly /user:[domain\user] "/path/to/mytask.exe". This prompts for the password, but that can be piped in with echo [password]|runas ...
Hi Guys any help would be much appreciated.
We have an application that’s installed at several locations but we are having an issue at one particular site. In short the application settings (My.) are not being saved after a reboot. The application is build in VB.Net v3.5 Framework and we are not experiencing any issues elsewhere.
This particular site is using roaming profiles and the network administrator ensures us that the correct permissions are applied to the user account(s) and all application data is being saved to the server. I’ve asked the network admin to check for the existence of the user settings file user.config in the Application Data directory and he says it doesn’t exist.
In our application we store the connection string to the database in the application settings under the user scope. If no connection string is present or if one is present and a connection to the database cannot be made then a form is shown asking the user for the database credentials. Each morning when the users boot the machine and opens the application for the first time they are asked for these credentials but if they close the application and restart it they are not asked for them. This indicates to us that the settings are being saved but once the pc is rebooted and the application is opened for the first time they are asked for the database credentials. This seems like the settings are not persisting after a reboot.
Any thoughts/feedback would be much appreciated.
I'm wondering if it's Code Access Security preventing the file from being written?
If the sysadmin at trouble site has implemented group policy folder redirection, the user's local/roaming profile could be getting stored on a network fileshare. Code Access Security is fairly picky about letting code read/write to/from network resources.
I'm sorry that I don't have more details than this, and I didn't find any sure-fire hits on google, but searching for "code access security", "fulltrust" and any network/fileshare keywords you can think of may get you farther.
I have an app that uploads documents to the server through the standard
When sent my application to the production server, I found out that they had the server load balanced. My solution to this was to place the upload directory into a network share and then create a virtual directory pointing to the share.
I have set permissions on the share and the file itself, but I keep getting "access denied" whenever I try to upload a document.
Where could I be missing permissions? Is it possible that IUSR needs to have access to the share?
Thanks.
FYI,
The answer to this solution for me was to setup temporary impersonation with a user account that had access to the share, the folder and the virtual directory.
Here's a link to the code that worked for me:
http://support.microsoft.com/kb/306158#4
I hope your site use anonymous access. Otherwise you will have a painful experience.
If it is so ( anonymous acess), then: The IUSR is a local user on the production servers and not a domain user. So it don't have access the the share. You will have to change that to a domain user ( in the site configuration and not on the application pool). And make sure that the application pool run on a network service ( this is the default ) and it should work.
Chances are that whatever your ASP.Net process is running as does not have access to the share.
So chances are you need to set up an IIS6 application pool to run as a domain user and have that domain user have access rights to the file share.
Don't forget to aspnet_regiis -ga {domainuser} so that the domain user can actually run asp.net applications.
When an ASP.NET application is running under IIS6.0 in Windows 2003 Server with impersonation, what user account is relevant for deciding file read/write/execute access privileges? I have two scenarios where I am trying to understand what access to grant/revoke. I thought the most relevant user is probably the identity specified in the Application Pool, but that doesn't seem to be the whole story.
The first issue concerns executing a local batch file via System.Diagnostics.Process.Start()--I can't do so when the AppPool is set to IWAM_WIN2K3WEB user, but it works fine if it is set to the Network Service identity. I of course made sure that the IWAM user has execute rights on the file.
The second involves writing to a file on the local hard drive--I'd like to be able to prevent doing so via the access control list via folder properties, but even when I set up all users in the folder as "read" (no users/groups with "write" at all), our ASP.NET still writes out the file no problem. How can it if it doesn't have write access?
Google search turns up bits and pieces but never the whole story.
what user account is relevant for [..] file read/write/execute access
As a rule: Always the user account the application/page runs under.
The IWAM account is pretty limited. I don't think it has permissions to start an external process. File access rights are irrelevant at this point.
If a user account (Network Service in your case) owns a file (i.e. has created it), it can do anything to this file, even if not explicitly allowed. Check who owns your file.
Process Monitor from Microsoft is a great tool to track down subtleties like this one.
A bit more searching reveals that the IWAM user isn't that well documented and we should stick with NETWORK SERVICE or a manually-supplied identity if we want to specify permissions for that user.