# Access Same Data from Windows and Linux Workstations ## Overview If your tenant has both a Windows workstation and a Linux workstation CCV can create a shared drive of non-encrypted storage that can be accessed by both workstations. Control of the security group permissions on files and folders must be controlled from the Windows workstation, but users will be able to perform normal folder navigation and file access from either workstation. Here's how it works: 1. CCV team mounts a drive to both workstations 2. `sh__admins` group members login to the Windows workstation and create folders for their separate projects to share data 3. On the Windows workstation, assign folder permissions to security groups that are appropriate 4. Users with the correct security group access can navigate the drive normally, according to their level of security group access ## Instructions ### 1. Contact CCV Please email `stronghold-help@brown.edu` to request a shared drive. Once our technicians have enabled your shared drive, you will be notified and can continue to the next step ### 2. Create Folders Only members of the security group `sh__admins` will have access to the shared drive by default. It is important for a member of `sh__admins` to create a folder structure inside the drive that can later be setup to allow access for users. ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58j_J7obWZ0F_AxNVP%2Fwin_ursawinlnx_folder.png?alt=media\&token=d2defa18-a328-402b-b269-2c2671becc38) In the above example our shared drive is `Data (H:)`, our top-level folder is `URSAWINLNX`, and we have two project folders (`project1` & `project2`). We are using a top-level folder because the drive may have different names on the two different workstations. ### 3. Assign Permissions You **MUST** assign privileges from the Windows workstation for those privileges to be enforced on the storage volume. To get started, right-click the folder and select "Properties" ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58qapOxUtc0Igph6_o%2Fwin_properties.png?alt=media\&token=60cafb5d-2265-4458-95a3-ddfddcf9b493) On the Properties window, select the tab labeled "Security" and then click the button labeled "Advanced" ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58r088jsIzUwQNSQ9p%2Fwin_advanced.png?alt=media\&token=577a2325-9578-4cb7-b9d2-dbfe3bae58cf) The Advanced window will show you all of the current permissions on that folder ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58rjTufkM3E7ihBVNy%2Fwin_permissions.png?alt=media\&token=c8bb0a97-5289-4b88-ad75-95918063ed9e) As you can see above, we have the group `sh_dev_test_admins` as our demonstration group that corresponds to `sh__admins` in a regular tenant, and thus has "Full control" of the folders `URSAWINLNX`, `project1`, and `project2`. We have given another group (`sh_dev_test_users`) "Read, write & execute" access to the folder `project1` but no access to `project2`; you will see the repercussions of this in the next section. To add a security group to a folder from this Advanced window, click the "Add" button ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58vEdvASWAoiCtROIq%2Fwin_entry.png?alt=media\&token=a5f11bb7-6422-42af-8ad0-a9009129f0bf) On this Permission Entry page you will need to click "Select a principal" to start assigning privileges to a new group ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58wHEkDPgg2KrYkrNu%2Fwin_select.png?alt=media\&token=abfdec58-e02d-4292-b68a-fc918a2fd21f) A new window will popup and give you a place to enter the group name you wish to select. **MAKE SURE TO CLICK "Check Names" BEFORE CLICKING OK!** If the group name is valid, you will see the `sh__` become underlined. Click "OK" to return to the previous window ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M58y7xR04AYuQ_i9puq%2Fwin_entry_users.png?alt=media\&token=47d21aff-29a2-4bc8-bf22-5f262318ebb4) Now that a valid group has been selected, the permission options will no longer be grayed-out. Make the changes you need to and click "OK" to save and get back to the Advanced window ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58V0P3T1UwFVnTOZiq%2F-M58rjTufkM3E7ihBVNy%2Fwin_permissions.png?alt=media\&token=c8bb0a97-5289-4b88-ad75-95918063ed9e) If everything looks correct, feel free to click "Apply" and then "OK" to save the new settings and exit this window. You are now ready to test the folder permissions ### 4. Test Access Permissions Testing permissions can be done from either the Windows workstation or the Linux workstation, but there are slight differences that we will point out #### Windows Folder navigation will be completely normal from the Windows workstation for members of security groups with access to the folders. Right-clicking a folder and selecting "Properties" will correctly show the permissions set in Step #3. If a user does not have access to a folder, they will not be able to view permissions on the folder ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M59-J5VThYBnRnUgfDq%2Fwin_ursawinlnx_project2_no-read.png?alt=media\&token=156e6bba-e8af-4869-b101-924ca38309e0) If a user does not have access to a folder, they will also not be able to open the folder ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M59-UTcVYHIaGAI9wm_%2Fwin_ursawinlnx_project2_error.png?alt=media\&token=248355b4-05e4-4a65-b3c3-935f72e05449) #### Linux Users on the Linux workstation can access folders and files on the shared drive, but the Linux Operating System is not aware of the permissions that were set on the Storage Volume from the Windows workstation; this causes some strange interactions with POSIX commands not returning what a user may expect. For example: the command `ls -la` would normally show the permissions on a folder or file, but in this case it returns the following ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M590hO8mMcNYnR45jFB%2Flnx_ursawinlnx_project1_ls.png?alt=media\&token=ceb1a1b6-8284-4ec5-b336-93d7fbc58d8f) That is not what was setup on the Windows workstation, but the OS isn't aware of that. Instead, we can use a storage volume command `nfs4_getfacl` to read the permissions of the folder to get the following response ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M591CkRUuIlI_U_-UzV%2Flnx_ursawinlnx_project1_facl.png?alt=media\&token=7d53aff8-0ccf-4092-a838-9db85d0b3f52) With `nfs4_getfacl` we correctly see `sh_dev_test_users` has access of some kind, as does the "OWNER" (which we know from Windows is `sh_dev_test_admins`) but what do those letters all mean? [The full documentation can be found here](https://www.osc.edu/book/export/html/4523), but the critical piece is the following ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M5935RfcS6Ev-lMjvc6%2FHOWTO__Use_NFSv4_ACL.png?alt=media\&token=42bd432d-5de9-4fe6-bad0-38ef715b8ef8) We should also test out what happens when a user who does not have permission tries to access a folder ![](https://240799936-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LcWdZhwLCll1J0u091B%2F-M58xbxiCQeCBeSI1W51%2F-M593I6mRy3efStQXtBt%2Flnx_ursawinlnx_project2.png?alt=media\&token=b5c0f013-ce3b-40df-a926-2564330576fc) As you can see above, POSIX commands return explicit "Permission denied" errors and `nfs4_getfacl` returns only the folder name, with no further details. The permissions set on the Windows workstation are respected on the Linux workstation!