System Administration
Showing results for 
Search instead for 
Did you mean: 

CIFS mount dropping because of Microsoft updates?

Valued Contributor

CIFS mount dropping because of Microsoft updates?

We have a 2003 Windows Server running IIS with data connectors to a Unix server for one of our applications.


This server is also mounted remotely from a Linux box via CIFS mount to the Share, as files are uploaded by clients, and I have a process on a Linux box which does some file management between a couple other systems internally.

I define the share and the mount works, until the system is rebooted, at which time I have to return to the server and create the SHARE and permissions..

This share is needs to be FULL Control for Everyone in order for the CIFS process I run on the Linux side to work..

I am an old Unix guy and it would seem I should be able to be a bit more explicit as to which use can Write to that directory with out using "Everyone" and Full Control?

The Linux system in question is NOT running SMB, it is mounting as if it were a typical NFS mount.

I found a reference on technet to DEP in 2003, where the boot.ini requires modification to the /noexecute=Opt<In>, OptOut, AlwaysOn or AlwaysOff.

I am curious if anyone has experienced something similar and have fixed it with the DEP mods to /noexecute=AlwaysOff?

Any insight appreciated.

Honored Contributor

Re: CIFS mount dropping because of Microsoft updates?

Let me reiterate to make sure I understood correctly:

The Windows Server 2003 is sharing a directory, and the Linux box is CIFS-mounting it.


The CIFS protocol requires that each remote mount is associated with a particular user, so either you're providing a username+password when mounting the share, or you've set up the share with guest access enabled: in the latter case, password will not be required but any operations done on the share from the Linux system by any Linux user will be associated with the guest user, in the viewpoint of the Windows server.


If you want the CIFS mount to happen automatically when the Linux box starts up, you should either specify the required domain+username+password using the appropriate options in /etc/fstab, or use the "guest" mount option to explicitly indicate that a password won't be required.


You could create a special user on the Windows server for the Linux access, e.g. yourdomain\linuxaccess, and use it in access control lists at the Windows server side.


On the Linux side, you can use the mount options uid=, gid=, file_mode= and dir_mode= to specify the permissions of the files and directories on the mounted share according to Unix conventions. See "man mount.cifs" for more information.


As a result, every action on the CIFS-mounted share on the Linux system would be subject to dual security checks: first, the Unix-style ownership/permission checks against the mode/owner/group specified with the mount options would dictate whether the operation request is sent to the Windows system or rejected locally on the Linux system. If this check is passed, the operation request is again checked on the Windows system according to the access level of the Windows user that was used when CIFS-mounting the share. As a result, if the mount was done using a Windows account with limited access, even the root user on the Linux server will be subject to access restrictions on the CIFS-mounted filesystem.


DEP does not seem at all related: it protects the running code in the RAM of a Windows system from modification (caused by programming bugs or some types of buffer overflow attacks). If there was a problem in accessing remote shares where disabling DEP was suggested as a workaround, I sure hope the suggestion was just a temporary workaround while a proper fix was being developed. When DEP was a new feature, I guess it caused a lot of strange corner cases and bad programming to be uncovered, but by now I would expect all the Windows filesharing code to be patched to work 100% with DEP enabled.