Open Gridberry
Start Gridberry on Windows 10/11, connect a model and select your Linux server, reached over SSH, as the environment. Choose Ask first mode so each change waits for you. Plan only is a good first look when the server is unfamiliar.
Workflows
add group to folder linux on a server you administer
03
Share a project folder with a team
You need to give one group read and write access to a shared folder on a Linux server you administer, for example /srv/app. Gridberry connects to the server over SSH, shows the current owner, group and permission letters with Shell, proposes the exact chgrp and chmod lines and waits for your approval before it changes anything. Afterwards the same listing shows the result, so you can compare the before and after yourself. The order matters: look first, change second, check third. Typical cases are a deploy folder, a shared upload folder or a project folder for a small team. Whatever the folder is, the same loop applies, and every command appears as a card with its real result, so the whole change can be read back later in the chat.
Look at the folder
Ask the agent to show the owner, the group and the permission letters of the folder. Shell runs ls -ld and the card shows the output, which you read before any change. Nothing changes at this step; it is a pure look-up of information.
Approve the change
The agent proposes chgrp for the group and chmod for the rights. You read each line, accept it and watch the exit code. A non-zero code means the change did not happen. Reject any line you do not understand and ask the agent to explain it.
Check the result
Run the listing again and compare it with the first one. Then test with a user from that group using one harmless command, because group membership applies after a new login. Keep the output; it is your record of the change.
Example script: a read-only access check
Run the access check script for /srv/app and show me the output.
- Shell
bash check_access.shexit 0 - Shell
idexit 0 - Shell
getent group appteam1 match - Shell
ls -ld /srv/appdrwxrwx---
waiting for your OK before the next stepRejectAccept
check_access.sh
#!/usr/bin/env bash
# Read-only access check for a shared folder.
# It changes nothing on the system.
set -eu
DIR=/srv/app
echo "User: $(whoami)"
id
groups
head -n 5 /etc/group
getent group appteam
ls -ld "$DIR"
echo "Check finished"This script prints who you are, your groups, the first lines of the group file, the members of appteam and the owner and group of /srv/app. It only reads information and changes nothing, so you can run it before and after every change and compare the output. Save it as check_access.sh, run it with Shell before and after the change, and keep both outputs so you have something to compare.
Add user to folder permissions linux: four tasks
Look at the server and the folder
Gridberry connects to your Linux server over SSH and runs ls -ld on the target folder with Shell, so you see the owner, the group and the permission letters before anything changes. It then runs getent group for the group you plan to use. In Ask first mode the agent pauses before every action that changes something, and you can switch to Plan only to read the steps with nothing executed. How to get sudo to work for a new user is a different problem: add the user to the admin group and log in again. Read the output of both listings before you go on. Keep that listing: it is your record of how the folder looked before the change, and it is what you compare against if you need to go back.
Create the group if it is missing
If getent group prints nothing, the group does not exist yet. The agent proposes groupadd appteam and shows the exact line in a card. You can edit the name if you prefer another one, and you approve the command before it runs. Afterwards getent group appteam shows the new entry, and you check the output yourself instead of trusting a summary. The group file /etc/group lists every group, so a copy of it taken beforehand lets you compare. When running sudo, missing root env vars can explain why a script that works for you fails for the administrator, so keep the first steps plain. If the name is already taken by an unrelated group, pick another name instead of reusing it, because a group that holds other users would give them access to the folder as well.
Set the folder's group
The agent proposes chgrp appteam /srv/app, which makes the group the owner group of the folder. You read the line in the card and approve it. Do not point the command at a parent folder or a mount point you did not intend; a card that names a different path than you expected is a reason to reject it. The exit code appears on the card, and a second ls -ld shows the new group name. People often search for "add group to folder linux" and find recursive commands, but a single folder is easier to review, so start there. Add members with usermod -aG appteam username, and remember that the change applies after the user logs in again. If an earlier mistake changed ownership under a root-owned path, recover from a sudo chown mistake by restoring from your backup.
Grant only the rights the group needs
The agent proposes chmod g+rx for read access or chmod g+rwx for write access, never chmod 777. It explains that the letters r, w and x stand for read, write and enter, and that g means the group. After you approve the line, the agent runs ls -ld again and you compare the permission letters with the first listing. Then you test with one account from the group and one harmless command. For a single person who searches "add user to folder permissions linux", the same check applies: put them in the group, never in the owner field. Keep the exit codes you saw: a success exit code on both cards, plus the matching ls -ld line, is your evidence that the step worked, and the next administrator can read it back in the chat.
