I had two computers running Windows 7, connected in a simple network: both were wired to my router via Ethernet cable. It seemed that it should be easy to view files on one computer, working from the other computer. For some reason, it wasn’t.
I started by setting up a HomeGroup. After screwing around with that for a while, I opted to “leave the HomeGroup,” on each computer, and revert to my usual approach of working with network settings. This decision was based in part on my previous impression that, whatever their intended purpose, homegroups didn’t necessarily add much, other than possible bugs and complexity. It might have helped if the homegroup had seemed to be designed for the specific purpose I had in mind, which was to restrict access to only certain users among the networked computers.
I knew that file sharing was easy enough if I gave full permissions to Everyone. That was the approach I had used previously. This time around, however, I decided that I wanted to learn about restricting permissions only to an intended computer or user. So I did not take the usual route. For the record, that route was available via Windows Explorer > right-click on the drive or folder to be shared > Properties > Sharing tab > Advanced Sharing > check the Share This Folder option > change or add the Share name as desired > Permissions > Add > Everyone > Full Control.
In other words, the problem that I was running into was that I could not figure out how to give file permissions to a specific user on another computer within my little network. The effort unfolded as follows. First, in the Advanced Sharing dialog (above), I would click on Permissions, and that would give me this:
No groups or users have permission to access this object. However, the owner of this object can assign permissions.
The object in question was one of the partitions on my hard drive. So I would click the Add button. Now I was looking at the Select Users or Groups dialog. It gave me the options to select a certain object type. The default was to include everything. I left that alone. The next option was to specify a location. It defaulted to the computer I was working on, and for some reason, it would not let me choose any other location. This made no sense. The user to which I wanted to give permission was my own user account on the other computer. That is, when working on the other computer, I wanted to be able to view files in this hard drive partition.
A search indicated that I was not the only person who found this frustrating. One comment stated that, unless I was running Windows Server, each computer would know only about its own user accounts. The idea there seemed to be that no computer would be able to look at another computer and say, “OK, I see that Ray is a user over there; so when it comes to listing Permissions options, I will offer not only the Everyone option but also the Ray option.” Windows 7 would evidently have nothing other than a door-open-door-closed approach: either someone outside this computer can come in, or else they can’t. That seemed ridiculous. Surely Windows 7 should have been able (a) to see that there was an existing network connection to computers B, C, and D, and (b) to see, if not all of the user accounts on each of those systems, at least the user currently logged in.
Someone said, “In order to provide permissions for a specific user, you must create a user on your local computer and give the credentials to the (human) user of the remote system.” This statement provoked a question: How do I do that? The reply was, Add users to the two systems as needed via Control Panel > User Accounts. That did not seem to be a solution: both of my computers already had a Ray (Administrator) account.
A HowToGeek webpage reminded me to make sure that both computers were on the same Workgroup. They were — I went with the defaults when installing Windows 7, and in any case I assume they wouldn’t have been able to see each other if they weren’t in the same workgroup — but for the record, the procedure there was to go into Control Panel > System > Advanced System Settings (or run SystemPropertiesAdvanced.exe) > Computer Name tab > Change workgroup. It occurred to me, upon reviewing this point, that a workaround might be to set up a workgroup including only the computers that would be allowed to talk to each other; set up Everyone permissions on those computers; and prevent others from gaining physical access to those computers. Then there would probably be full access among workgroup members and nobody else. This scheme would presumably cease to provide security as soon as someone elsewhere on the network figured out the name of the alternate workgroup and changed their own computer’s workgroup to that alternate name. Presumably, though, I would see them among the computers on my system. Perhaps I could set up a batch file to open up a Windows Explorer session focused on the network members, every few hours or days, so as to eyeball the current situation.
It also seemed that it should have been possible to require outsiders to enter a password before gaining access to files, even if I had given full rights to Everyone. The concept there would be that, yes, you are one among everyone in the world, and therefore you have full rights to everything on my computer — but if you don’t mind, I would still like to impose a password requirement. Apparently there *was* a password requirement somewhere, somehow, though it had been a while since I had seen it appear on my computers, when I had been giving full rights to Everyone; I was actually not too sure how a person could go about imposing it. But evidently it didn’t matter: according to one report, Windows 7 was not requesting the password for a specific user account on the shared machine, but (at least with Everyone permissions) was rather asking for any user’s account on the remote machine — and since Windows had no idea what accounts might exist on the remote machine, apparently it would accept any gibberish as valid for security purposes. No guarantees on this, but that’s how it sounded at the moment.
I decided to experiment. I went into Windows Explorer and made sure the Folders pane was visible (View > Folders). I clicked the minus symbol next to the Network entry in the Folders pane, so that no specific computers were visible under Network in the Folders pane. Then I hit F5 to refresh the view, and I proceeded to explore the Network entries. The situation seemed to be as follows: if I did not check the “Share this folder” box for a given drive or folder (right-click on the drive or folder to be shared > Properties > Sharing tab > Advanced Sharing), that drive (or folder) would be shown as Not Shared in the Properties dialog, and no entry for that drive would appear in Windows Explorer under the specified computer. As soon as I checked the “Share this folder” box and exited the Advanced Sharing dialog, however, that drive would be shown as Shared in the Properties dialog, and an entry for it would appear under Network in Windows Explorer on the other machine.
It developed that Windows would automatically create “read” permissions for Everyone as soon as I enabled sharing for a drive. But I could change that. I could remove Everyone and add Ray as a user with Full Control permissions for that drive. That worked: when logged in as Ray on the other (i.e., remote, not shared) machine, I could edit and delete files on the shared drive; and as soon as I removed Ray as a user (or curtailed all of his permissions) on the shared drive, I ceased to have the power to edit and delete files on the shared drive. Instead, I would get an error:
File Access Denied
You need permission to perform this action.
In other words, Windows did not automatically see that there was a valid user named Ray on the shared machine; but as soon as I took the step of making that user relevant to a specific drive via sharing permissions on the shared machine, Windows would make the contents of that drive visible to a user logged in as Ray on the remote machine. So I went ahead and made Ray the only user with permissions for each of the drives and folders I wanted to share on the shared machine, and verified that I could work with each of those drives and folders from the remote machine.
Next, on the shared machine, I tried removing Ray as a user with permissions for drive W, and tried adding a user named Dude. This gave me an error message:
Name Not Found
An object named “Dude” cannot be found. Check the object types and location for accuracy and ensure that you typed the object name correctly, or remove this object from the selection.
So, OK, Windows was paying attention. There was a limited set of possibilities for users to whom I could give permissions. A search led to indications that various local groups and individual accounts were installed by default in Windows 7. To view the ones installed on my computer — using an option apparently available only when logged in as an administrator, and only on the Professional, Ultimate, and Enterprise editions of Windows 7 — I ran compmgmt.msc (i.e., Computer Management) and, as advised, went into its System Tools > Local Users and Groups. Users, at this point, included the built-in Administrator and Guest accounts, plus Ray. The list of 15 groups included Administrators, for example, and Power Users, and plain old Users. A bit of experimentation seemed to suggest that I could probably give shared drive permissions to any of these.
To make sure I understood the situation, on the remote machine I went into Control Panel > User Accounts > Manage Another Account. I had turned off the Guest account. Now I clicked on it and selected the Turn On option. I went into Shut Down > Switch User > Guest. As Guest, I went into Windows Explorer. I verified, on the shared machine, that Ray was still the only user listed in the Permissions dialog. In the Guest account on the remote machine, Windows Explorer showed both the remote and shared computers; but when I clicked on ACER, the shared computer, I got an error:
\\ACER is not accessible. You might not have permission to use this network resource. Contact the administrator of theis server to find out if you have access permissions.
Logon failure: account currently disabled.
I wasn’t sure what that last remark was about. The Guest account seemed to be working fine. I ran a Google search in Internet Explorer and played with a few other programs. I hadn’t previously played with Guest accounts much, so now I took a moment to see whether the Guest could view Not Shared folders right there on the remote machine. It could. It tentatively seemed that sharing was a concept only for network purposes. I switched users back to Ray and turned off the Guest account.
Now I had a new problem on the remote machine. When I attempted to view the drives on the shared machine to which I had given Ray full permissions, I got an error: “Windows cannot access [the shared machine],” whose details were, “The network path was not found.” Apparently that brief detour into the Guest account had upset the system. I chased down this problem in a separate post.
Once that was done, I wanted to test this sharing situation further, using options involving wireless and someone else’s computer. It did tentatively appear, though, that the keys to the solution of my own problem were (a) to have an account on the remote machine with a name identical to that of the user on the shared machine who had been given permissions regarding a drive or folder, and (b) to resolve any other network connectivity problems that might be interfering with file sharing.