Re: G Share Free Server
Varyarmah Knox
The issue for these two users appears to happen fairly close together and was only noticed on Wednesday of this week, long after an server side updates. The problem occurred again this morning so after I chatted with the person with G drive issues, I confirmed that the other user had issues with her S drive folder as well around the same time. No other users have reported these problems.
I know it was a long post, but I included those deets. Single file server 2016 fully patched so no replication. So to be clear, we have multiple folders with varying permissions shared over a UNC that is mapped to a single drive letter.
Physical server of VM ?? What is the resources of the server 2016 when this occurs (esp CPU & RAM "free, cached, available). Any AV on file server ? How many shares (opened folders and open files) when this happens ?
We have over 60 users with file server credentials (not all simultaneously accessing it) but only 2 are reporting the problem so far. We have two primary shares out of which each one concurrently has about 55 connections with a couple of dozen open files under each at any given time.
g) I rebooted the server and had one user change their password shortly after. When she rebooted, she was able to access it. I thought I had fixed it then, but the other user still seems to be affected and shortly after I double checked and the problem resurfaced for the other user again.
Have you tried disabling any third-party software that might be accessing the folders as the users work in them, such as backup software, cloud storage (dropbox etc) or antimalware software on both client and server?
Then some applications like PDF writers, AutoCAD etc actually create temp files at the destination (in OPs case, the shared folder). So a combination of factors (DC network, file server network, local credential manager, Windows explorer previewer, RAM leaks and that causes weird issues.
Windows Defender is the only AV we have on both that server and endpoints and I can see no warnings or quarantine triggered on either side. The issue started to be noticed just two weeks ago, long after our last server side update.
Share servers are abstracted away from end users. Drivers operating indriver_handles_share_servers = True mode manage the lifecycle of these shareservers automatically. Administrators can however remove the share servers fromthe management of the Shared File Systems service without destroying them. Theycan also bring in existing share servers under the Shared File Systems service.They can list all available share servers and update their status attribute.They can delete an specific share server if it has no dependent shares.
To manage a share server means that when the driver is operating in thedriver_handles_share_servers = True mode, the administrator can bring apre-existing share server under the management of the Shared File Systemsservice.
To unmanage means that the administrator is able to unregister an existingshare server from the Shared File Systems service without deleting it from thestorage back end. To be unmanaged, the referred share server cannot have anyshares known to the Shared File Systems service.
The driver_options is an optional set of one or more driver-specificmetadata items as key and value pairs. The specific key-value pairs necessaryvary from driver to driver. Consult the driver-specific documentation todetermine if any specific parameters must be supplied. Ensure that the sharetype has the driver_handles_share_servers = True extra-spec.
The share_network_subnet is an optional parameter which was introduced inTrain release. Due to a change in the share networks structure, a sharenetwork no longer contains the following attributes: neutron_net_id,neutron_subnet_id, gateway, mtu, network_type, ip_version,segmentation_id. These attributes now pertain to the share network subnetentity, and a share network can span multiple share network subnets indifferent availability zones. If you do not specify a share network subnet,the Shared File Systems Service will choose the default one (which does notpertain to any availability zone).
The service can automatically delete share servers if there are noshares associated with them. To delete a share server when the lastshare is deleted, set the option: delete_share_server_with_last_share.If a scheduled cleanup is desired instead,automatic_share_server_cleanup andunused_share_server_cleanup_interval options can be set. Only one ofthe cleanup methods can be used at one time.
Any share server that has a share unmanaged from it cannot beautomatically deleted by the Shared File Systems service. The same is truefor share servers that have been managed into the service. Cloudadministrators can delete such share servers manually if desired.
The limits can be ignored when placing a new share created from parentsnapshot in the same host as the parent. For this scenario, the share servermust be the same, so it does not take the limit in account, reusing theshare server anyway.
From time to time, collaboration session hosts might want to share a web application or other locally running servers or services with guests. This can range from other RESTful endpoints to databases and other servers. Visual Studio Live Share lets you specify a local port number, optionally give it a name, and then share it with all guests.
The guests will then be able to access the server you shared on that port from their own local computers on the same port. For example, if you share a web server running on port 3000, guests can access that same running web server on their own computers at :3000.
This connection is accomplished via an improved security SSH or SSL tunnel between the host and guests and authenticated via the service. This connection mechanism helps to ensure that only people in the collaboration session have access.
As a host, be selective about the ports you share with guests. Stick to application ports (rather than sharing a system port). For guests, shared ports will behave exactly as they would if the server/service were running on the guest's computer. This behavior is useful, but it can be risky if you share the wrong port.
If the port is already being used on the guest's computer, a different one is automatically selected. As a guest, you can see a list of shared ports (by name, if specified) on the Live Share Explorer tab or the VS Live Share tab. The list is under Shared Servers. If you select a port, that server opens in your browser. You can also right-click and select an option to copy the server link to the clipboard.
Modern developers frequently use of a variety of command-line tools. Live Share allows hosts to share a terminal with guests. The shared terminal can be read-only or fully collaborative, so you and the guests can run commands and see the results. You can make terminal output visible to guests. You can also let them run tests or builds or even triage environment-specific problems that only happen on your computer.
By default, terminals aren't shared because they give guests at least read-only access to the output of commands you run (if not the ability to run commands themselves). This default configuration allows you to run commands in local terminals with reduced risk and share only when you need to. And only hosts can start shared terminals. This limitation prevents guests from starting one up and doing something you aren't expecting.
At this point, you can choose whether to make the terminal read-only or read/write. When the terminal is read/write, everyone can type in the terminal, including the host. So, as a host, you can easily intervene if a guest is doing something you don't like.
To be safe, you should give read/write access to guests only when you know they actually need it. Stick with read-only terminals when you just want the guests to see the output of commands you run. Keep in mind that read/write access gives guests the same access to your terminal that you have. They can run any command on your computer that you can.
There are two ways to go about this that I know if. One is unreliable, but probably good enough for most scenarios. One is extensive, but hard to implement at any scale that exceeds a handful of user connections.
The Kinda-Sorta Way: Select System Tools >> Shared Folders >> Open Files to see what files are open on the file server. From there you can correlate the user accounts that have open files to the shares that they are connected to.
However, that can be insufficient. Don't believe me? Go into Computer Management and select System Tools >> Shared Folders >> Sessions to see who is connected. Then look at the # open files column. Some sessions should have 0 open files. How do you know what share they are technically connected to? I'm glad you asked...
The Extensive but Hard to Scale Way: Perform net share [sharename] on each share in question to get a list of the users that are connected to it. In my testing, even users that have no open file are listed.
You can also utilize the Share and Storage Manager administrative tool in Server 2008 and beyond instead of Computer Management. Find the share in the list of shares, and then in the action pane to the right click "Manage Sessions." You will see a list of sessions including those that have zero open files.
But... but... I want to find a specific user without querying each share! If you have a specific user that you want to track down, it appears that your only means of finding that information is to query each share and eyeball it to find the user you want. And by eyeball I mean piping output to findstr or select-string. One could extrapolate the workflow to a script that enumerates all available shares, queries for connected users, and searches the output for the user in question, but that appears to be an exercise for the reader and not something that Microsoft has included as a native feature.
b1e95dc632