Teraserver too many open files

A quick temporary fix is closing al session on the share for that specific user this will allow them to log back on with their regular profile. But doing that on semi daily basis not an option and leads to a lot of user frustration.

I did try the above option of creating a logoff script like suggested above but this destroys the roaming of profiles completely and on top of that even more file handles are left over!

As you said, terminate the syncing will cause data lose. I it is a roaming profile, can you find the exact file which was still connecting? After logging off from a terminal server the profile is synced to the file server.

In order to do that, the user profile service sets "write" locks on the directories of the user's profile:. Unfortunately those seem not to get removed from time to time so that a later read say next morning on logon fails and leads to a temporary profile on the terminal server. At first we thought it might be related to one terminal server but disabling logon to that server only slightly reduced the problem.

Slightly off topic: we'd love to use profile disks as that might reduce or even solve the problem but unfortunately profile disks are a per rds farm setting where you cannot leave out certain users read administrator.

And being able to only log on to ONE terminal server at a time in order to do updates is not feasable at all. I've seen similar issues. Most of the time it is as you describe on the profiles, but once in a while we also see it on other files that are in-use during logoff.

One particular application presents a "Are you sure you want to quit? Best solution we've found is to kill the handle from the file server. We temporarily removed anti-virus from the server thinking that maybe it was causing the problem but the issue continued after this change.

Killing the open file handle on server side works. But this is something that cannot be done on a daily basis as the customer's work time starts WAY before ours.

We are going to reboot the terminal servers each night at around 4am and see if that remediates the problem. The reboot works over here, but we have had one or two cases where we end up with locks in the middle of the day. We're trying to come up with a reproducable case so we can open an issue with Microsoft, but it is so sporadic we have yet to come up with a pattern. We are experiencing the same issue and have not been able to fix it, tried several workarounds like daily reboots and closing all open files.

Rebooting the server on a daily basis is working but as Damon Durand pointed out it happens from time to time that a user logs off in the middle of the day and gets a problem logging on in the afternoon. We cannot experiment on that customer's site as this has been a rather touchy subject in the past weeks. I tried that in a demo environment and it seemed not to have any unwanted side effects. However if a user had the "require password change at next logon" flag set in active directory I only got a mean error from rdp As I never had the temp profile issue in the demo environment I cannot say for sure if that is a solution to our problem.

We have the same issue in nearly all of our environments where the server for storing the roaming profiles is running under R Depending on the infos from our customers it only happens when the user is connected for 10 hours and more, so we changed two options via GPO and the error seems to be gone.

We have the same issue in serveral environments where we have Windows R2 servers as a fileserver for the profiles. We have no problems with Servers. We checked the Maximum lifetime parameters as shown on some spotted Servers but some of the servers had already the 18 hours Setting and still the same Problem. We're having the same issues like everyone else.

Even opened a ticket with Microsoft Professional Support but they suggested premier support for a root cause analysis. Decided to continue to have a look and are currently trying a workaround. On the file server we have created a task that executes a powershell command around 3AM every night:. This way, in the morning, the users shouldn't have any locked files and won't get temporary profiles.

Update: I did try the round robin variant at another customer site. This was a complete new installation so I decided to test it there. Unfortunately I did get the temporary profile issue within the first week.

I decided to disable logon with temporary profile via gpo in order to prevent users from losing data when working with temporary profiles. Reason for this is that there is a document management software in use that writes documents that are checked out to the user's temporary files folder Several of our customers also have this problem, in our case with Windows Server without R2 in connection with roaming profiles.

We also tried different registry changes regarding to SMB-protocoll on the terminalserver and fileserver, but without any success on the affected servers. As a workaround we deployed new "blank" Windows Servers fileservers for the roaming profile share, but we cannot tell our customers to deploy new fileservers only because of not working roaming profiles.

That's not accurate. The User gets a temporary profile, because folders are locked on the Fileserver. We only have 1 RDS Server, no farm. There are too many profile copy errors. Refer to the previous events for details.

Windows will not log any additional copy errors for this copy process. Checking on the File Server we can see a open session of the user experiencing the problem with over a folder locks. Killing those open folders will fix the Problem temporary but we experiencing this more often and by more Users. We got several customers with exactly the same issue.

Complete fresh installations, all updates installed. I have encountered the same issue with a client this week and have had a support case with Microsoft for last days with no solution in site and am considering scrapping farm and roaming profiles all together. Performed in-place upgrade of R2 Terminal Servers to R2 and configured in a farm. Temporary profiles occur randomly. Some relation to open files from roaming profiles but nothing definitive. We've enabled roaming profiles per GPO and now encounter the exact same issue with over directories in write lock on our file server.

The odd thing is: Regardless if I restart the terminal server s , the files keeps locked on the file server. Really annoying thing and I have currently no clue on which screw I need to screw User logon sessions still remain open on the server for minutes after logging the users off net sessions , with hundreds of the user's roaming profile files staying open on the server.

Found these logoff-related events on the client Win 8. So apparently there is still communication between server and client regarding logoff seconds after the user initiated the logoff.

This seems the solution. However, the session remains listed in the ' net sessions' list, with the following files open server: Computer Management-Shared Folders-Open files :. INI Read ,. Office Office Exchange Server. Not an IT pro? Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. Asked by:. Archived Forums. File Services and Storage.

Sign in to vote. Saturday, July 18, PM. Hi, The problem is that the session between RDS server and file server still exists after using logged off.

Tuesday, July 21, AM. Hi Shaon, the open files are all part of the users' roaming profile. Thursday, July 23, AM. We also experience similar problems, resulting in temporary profiles randomly. There is one R2 fileserver en two RDS servers. Any ideas? Friday, July 24, PM. Hi, Sorry for the delay in reply.

Tuesday, August 4, AM. Hi, the open files we observed actually weren't files but directory handles. Add these lines:. You can change the limit of open file descriptors for a specific service, rather than for the entire operating system. Open the service settings using systemctl :. To make sure if the values have changed, get the service PID:.

When changing the limit on the number of open files for a web server, you also have to change the service configuration file. In this article we have learned how to solve the issue when the value of open file descriptor limit in Linux is too small, and discussed some options of changing these limits on the server. Notify me of followup comments via e-mail. You can also subscribe without commenting. Leave this field empty.

Home About. September 1, Linux. Related Reading.