Storage for Educational Projects: Permissions, Quotas and Folders

Why tidy up course data at all

Course projects often start simply: “send the file in chat” or “bring it on a flash drive.” While there are few files, this seems quick. But once teamwork, several deadlines and different versions of the same report appear, data spreads across messengers, personal clouds and random laptop folders.

The usual outcome is the same: someone brings the “latest version” which is actually two days old; part of the dataset is lost during copying; the instructor receives one version while the team discusses another. Worse still, files may be shared “with anyone who has the link,” and personal data from surveys or medical observations can leak outside the group.

Even in a simple course project, different types of materials usually need to live in one place: documents (requirements, plans, protocols), code and models, data (tables, measurements, images), reports and presentations, plus templates and instructions.

“Order” in storage for course projects isn’t about pretty folders. It’s about clear rules that eliminate constant clarifications: where the final version is, who can edit data, where to put results, how much space someone can use, and what to do if someone deleted something important.

Imagine a small research team of four: one collects data, another writes code, the third makes visualizations, the fourth prepares the report. Without rules, you spend the end of the semester hunting for the “right folder” and merging versions instead of improving results. With rules, time goes to work, not recovery.

Goals and roles: who should do what in storage

Order starts not with folders but with agreement: who uses what and who is responsible for what. Without roles, the familiar picture appears: someone accidentally deletes a file, someone saves "final_definitely_latest(3).docx", and some results go to flash drives and vanish.

Usually four roles are enough—simple and with clear permissions:

• Student: uploads materials, keeps drafts, places final versions in the team’s shared folder.
• Supervisor: reviews everything, comments, approves final files, and opens access for external reviewers if needed.
• Lab assistant / methodologist: maintains templates, raw data for labs and keeps instructions up to date.
• Administrator: configures the structure, access groups, quotas and backups.

Next, divide data into two layers: personal and shared. Personal = drafts, temporary exports, notes. Shared = assignments, raw datasets, “to submit” reports, experiment protocols, presentations. This keeps personal files from cluttering the team area and prevents shared files from hiding on laptops.

Minimum requirements for storage to be a working tool:

• search by name and content;
• change history (or at least versioning) to roll back after a mistake;
• access from classroom and home with the same permissions.

Define responsibilities briefly. For example: the administrator creates project folders and sets basic permissions; the supervisor confirms participants and the “submission” folder; the administrator monitors free space and warns in advance. Then students don’t fiddle with settings and don’t keep important files “just in case” on flash drives.

Access rights: a simple scheme that works

Start with “closed by default.” A new folder is available only to the owner and the supervisor. Access is added as needed, not “just in case.” This reduces accidental deletions, version confusion and leaks.

Save time by using groups instead of assigning rights to each person. Create 3–5 clear groups for the course or lab, and add people to groups rather than configuring dozens of folders manually. Changing participants (someone leaves, someone joins) won’t break the system.

Explain permissions in simple levels so everyone understands them:

• Read: can view and download, cannot change.
• Edit: can add and modify files, cannot grant access to others.
• Manage access: can change permissions and owners—reserved for responsible people.

For external participants (interns, partners, invited experts) use the rule “separate access.” Don’t give them access to the course-wide shared folders. Create a separate project folder and limit it by time and membership. For example: a team collaborates with a partner and moves final materials to a Final folder where only the supervisor can edit before submission.

To maintain order for years, fix responsibilities in advance:

• the folder owner is responsible for structure and currency;
• the curator (instructor/supervisor) approves participants and permission levels;
• participants edit only their parts and follow naming rules.

Quotas: how to avoid “disk full” at the worst time

Quotas aren’t meant to be stingy; they keep storage manageable. Without limits, one active project (or a couple of uploaded videos) can quickly consume space and hurt everyone.

Two clear approaches: per-user quota and per-project quota. In practice, a mix works well: a small personal quota for each user and a larger project quota for the project folder.

For heavy data set rules, set specific guidelines from the start. Experiment videos, raw measurements and large datasets grow unnoticed, especially when copies are re-saved. Agree that such data stays in a designated project folder with clear names and no “just-in-case” duplicates.

Set threshold notifications to avoid last-minute panics:

• 70%: a soft warning reminding teams to check duplicates and drafts.
• 85%: notify the supervisor and propose a cleanup plan.
• 95%: temporarily block new uploads except for responsible personnel.

If space runs out, don’t just ask “delete something.” Follow the plan: archive completed stages, move heavy originals to cold storage, remove obvious clutter (duplicates, temporary exports), and if necessary, review the project quota if the volume is justified.

Quotas work best when tied to course tasks and communicated to all participants in advance.

Folder structure: consistent and easy to use

Storage works better when everyone follows the same logic. Students find data quickly, instructors check it faster, and projects don’t end up with “last_final” in ten different places.

Single root

Agree on a root scheme and don’t change it mid-semester. Two common options suffice: by organization (faculty/department/year/project) or by subject area (lab/topic/project). The important thing is that the path makes it obvious where you are, which year and what the work is.

Keep a Shared_Materials folder at the year or course level with templates, guidelines and naming rules. That prevents copying these files into each project and them drifting into different versions.

Inside the project

A uniform project template saves time and reduces chaos. Numbering folders keeps the same order across any file manager and OS:

• 00_Admin (requirements, team list, plan, protocols)
• 01_Raw_Data (raw exports, surveys, measurements, datasets)
• 02_Analysis (scripts, tables, calculations; include a Drafts subfolder if needed)
• 03_Reports (presentations, final text, PDFs)
• 99_Archive (obsolete and closed)

Keep drafts separate from final files. For example, use 02_Analysis/Drafts and 03_Reports/Drafts and agree that grading is done only from 03_Reports/Final (or files explicitly marked as final).

File naming doesn’t need to be long—use short, predictable rules:

• date at the start in YYYY-MM-DD format;
• version as v01, v02 (not “new2”);
• author or group short: ivanov, grp-21;
• status: draft or final;
• avoid spaces and special characters; use underscores.

Example: 2026-01-11_report_v03_grp-21_final.pdf. In a month you’ll still know what it is and find it quickly.

Step-by-step setup of a new project in 30 minutes

If every new project is set up the same way, students start working faster and data doesn’t scatter across personal folders and flash drives.

30 minutes on the clock

• 0–5 min: create the project folder template: 00_Admin, 01_Raw_Data, 02_Analysis, 03_Reports, 04_Publication, 99_Archive. Add README_Where_to_put_files.txt and Team_List.xlsx.
• 5–10 min: create users and groups. Minimum two groups: Project_Team and Project_Reviewers. Add new participants only to groups.
• 10–15 min: assign permissions. Team = read/write in 01–04, prevent deletion in 01_Raw_Data (if possible). Reviewers = read everywhere, write only in 03_Reports and 00_Admin.
• 15–22 min: set up work and personal zones. Inside the project create 02_Analysis/Team and 02_Analysis/Personal/ivanov_i (one folder per person). Personal folders are visible only to the owner and supervisor.
• 22–30 min: test access “as a user.” Log in with a test student and a reviewer account: create, rename, delete files and open reports.

Leave a short guide in the project root so newcomers don’t guess:

• raw files only in 01_Raw_Data, do not rename without agreement;
• team work in 02_Analysis/Team;
• personal drafts in 02_Analysis/Personal/LastName_FirstInitial;
• final versions in 03_Reports;
• don’t delete old work—move it to 99_Archive.

Backups and versions: so a mistake doesn't cost a semester

A single accidental edit, deleted folder or “save over” can destroy weeks of work. Separate two protections: versions (quick rollback) and backups (recover if everything fails).

Protect what’s hard to reproduce first: code and configs, raw data and measurements, intermediate results, reports and presentations, instructions and methodology descriptions.

Good habits: don’t create many “final_final” files—record changes by meaning and date, e.g. Report_2026-01-10_method, Report_2026-01-11_supervisor_edits. Even better if the storage supports file versioning or folder snapshots—then rollbacks take minutes.

Agree retention periods: active projects keep versions and frequent copies until the end of the semester; after submission, frequency decreases but recovery remains possible; after defense or publication, move to a separate read-only archive.

A recovery plan should be clear:

• deleted folder — restore from trash or snapshot;
• overwritten file — restore the previous version;
• mixed-up versions — compare dates, restore the needed one and move the old one to _archive;
• “everything failed” — recover from backup on a separate medium.

Keep a minimal change log: who changed what and why. It can be a single text file in the project root with dates and short notes.

If the course infrastructure is on centralized server storage, these rules are especially helpful. For example, organizations that assemble storage and servers with support from GSE.kz benefit from unified templates and clear roles, which speed up recovery and incident handling.

Common mistakes and how to avoid them

The most frequent problem is default “everyone” access. It seems convenient until someone deletes a group folder, overwrites measurement results, or exposes personal data. Rule: grant access only to those who actually need it and only at the required folder levels.

Second mistake: granting permissions to individuals instead of groups. Today a team has three students, tomorrow one is on leave and a new student arrives, and old permissions stay attached to departed accounts. Use groups like Course-2026 or Project-Team1, and manage membership inside groups.

Third issue: personal and project files mixed in one folder. Drafts and clutter end up in the project and important results get lost. Separate personal, working and submission materials.

Fourth: no unified template—each project is different. That makes grading harder and searching slower. A single stable template that fits most cases is better than many “perfect” variants.

And quotas: without them, one project with videos or raw data fills the disk and everyone suffers.

A set of habits that solves most problems:

• minimal necessary access, no global read/write for everyone;
• assign permissions to groups, not users;
• separate personal, work and submission folders;
• adopt one template and don’t change it on a whim;
• set quotas for projects and users with headroom for peak loads.

Example: one student uploaded 200 GB of videos to a shared folder and the adjacent group could no longer save reports. With a project quota, the issue would be limited to one team and an instructor would have received an early warning.

Quick checklist before the semester starts

Before giving students access, check the basics. It takes 10 minutes and saves weeks when submissions begin and nothing can be found.

10-minute checklist

• Project folder created from the template and an owner assigned (usually the instructor or a responsible assistant).
• Access granted to groups (e.g., Group-101, Assistants, Instructors) rather than to individual users.
• Quotas configured for groups and participants, with fill-level notifications enabled.
• Naming rules fixed and a clear place for final submissions (e.g., a FINAL or Submission folder).
• Location of past project archives and who moves them after completion is defined, with a deadline (e.g., “2 weeks after grades are posted”).

Mini-test scenario

Open the project as a student: can you tell within 30 seconds where to upload work, where to get data and where not to write? Then open it as a reviewer: can you quickly find the final version and see the author?

Example scenario: lab work and a mini research project

Imagine a course where six teams do lab work and a small research project on the same storage. The instructor has their own folder and each team has a separate area. This reduces the risk of files going to flash drives, getting lost in messengers, or mixed between groups.

Access scheme: each team has write access only to its folder; teams cannot see others’ folders. The instructor and assistant can see all teams and edit as needed. You can add a read-only “observer” role if required.

Example structure

A workable layout:

• 00_Admin (instructor only: assignments, criteria, templates)
• 01_Shared_Dataset (common dataset, read access for all)
• 02_Teams (inside: Team_01 ... Team_06)
• 03_Submissions (teams write only into their subfolders, instructor reads all)
• 99_Archive (restricted access)

Inside each Team_XX predefine the same folders: Data, Code, Results, Report. Anyone opening Team_04 will immediately understand where things are.

Set team quotas, e.g., 10–20 GB per Team_XX, so one bad export doesn’t consume the entire disk. Give 01_Shared_Dataset a separate limit because shared datasets are often bigger and shouldn’t eat into team quotas.

End of semester

After submission, set Team_XX and 03_Submissions to read-only for students. The instructor keeps full access, moves the best work to 99_Archive and records final versions. Materials remain available for appeals and examples but cannot be accidentally overwritten.

Next steps: how to implement this without pain

Start with agreements. When rules are clear, storage stops being “someone’s personal folder” and becomes shared infrastructure.

Step 1: gather requirements

A single 30–40 minute meeting is enough to outline:

• how many concurrent users (students, instructors, assistants);
• how many active projects per semester and file types (documents, code, video, raw data);
• retention periods (until grading, until defense, long-term for reproducibility);
• where data should be accessible from (classroom, dorm, remotely);
• what cannot be lost (final reports, source files, measurement protocols).

Then appoint one technical administrator and one policy owner (templates, permissions, quotas). Decisions get made quickly instead of “like last time.”

Step 2: standards, pilot, rollout

Agree on one folder structure and one simple permissions scheme at the department or lab level. Aim for 80% fit rather than ten “perfect” versions.

Move in small steps:

1. pick 2–3 projects for a pilot;
2. configure folders, permissions, quotas and naming rules;
3. run a 10-minute onboarding;
4. collect feedback after a week;
5. adjust templates and make them the standard.

If reliability, availability or support are bottlenecks, consider a server-based storage solution with maintenance. In Kazakhstan, such services are often delivered turnkey on locally sourced workstations and servers—GSE.kz provides hardware, service and help meeting local content requirements.