Om en ny ZimaOS-medlem beviljas läs- och skrivbehörighet i delningsgränssnittet men ändå får meddelandet ”åtkomst nekad”, ska du inte omedelbart köra rekursiva ägarskapskommandon över hela lagringspoolen. Källtråden från mars 2026 testade flera teorier om ägarskap, genomförde en fullständig återställning och nådde fortfarande ingen bekräftad grundorsak.
Den hållbara felsökningsmetoden är att skilja ZimaOS-/Samba-behörighetslagret från det underliggande Linux-ägarskapslagret. Återskapa problemet i en liten ny mapp först, jämför administratörens och medlemmens åtkomst och granska först därefter den exakta värdsökvägen som berörs.
Medlemsbehörigheten såg korrekt ut i gränssnittet
Administratörskontot kunde komma åt datan, medan ett nyskapat konto med namnet Andres hade tilldelats läs- och skrivbehörighet men fick ett behörighetsfel när det öppnade filer.
Aktuella ZimaOS stöder Samba-behörigheter per användare
Den aktuella ZimaOS-dokumentationen skiljer mellan medlemsåtkomst och gäståtkomst och låter en hanterare bevilja antingen läsbehörighet eller läs- och skrivbehörighet till en Samba-delning. En medlem med läs- och skrivbehörighet bör kunna hämta, ladda upp, byta namn på och ta bort filer i delningen, förutsatt att det underliggande filsystemet är åtkomligt.
Aktuell Samba-konfiguration med flera användare i ZimaOS är den rätta utgångspunkten innan du använder kommandon på skalnivå som kopierats från en äldre tråd.
Återskapa problemet i en helt ny testmapp
Skapa en liten testmapp via det aktuella filgränssnittet på den avsedda datadisken. Dela endast den mappen med den nya medlemmen med läs- och skrivbehörighet och anslut sedan från medlemmens klient med medlemmens inloggningsuppgifter.
Om testmappen fungerar men migrerade eller äldre kataloger inte gör det, är problemet troligen kopplat till dessa sökvägar eller deras ägarskap. Om även den helt nya mappen som skapats i gränssnittet inte fungerar, är problemet mer omfattande och bör hanteras som ett möjligt konto-, Samba- eller ZimaOS-behörighetsproblem snarare än som ett problem med äldre filägarskap.
Använd Linux-ägarskap som en diagnostisk signal, inte som en blind lösning
Tråden granskade användar-ID:n och katalogägarskap och hittade sökvägar under /DATA/.media som ägdes av olika Linux-användare och grupper. Det gjorde en ägandemissanpassning för migrerade data plausibel.
Ett föreslaget rekursivt chown Åtgärden resulterade sedan i många felmeddelanden med ”Åtgärden tillåts inte” i programhanterade data. Det är en varning mot att tillämpa ett enda ägarkommando på breda systemträd eller AppData-träd. Att ändra ägarskap rekursivt kan få containrar eller tjänster som förväntar sig specifika UID:er och GID:er att sluta fungera.
Använd id, ls -ld, och en liten testfil för att förstå exakt vilken sökväg som misslyckas. Ändra inte orelaterade programkataloger.
En fabriksåterställning var inte en bekräftad lösning
Efter omformatering och ominstallation rapporterade författaren fortfarande fel med medlemsbehörigheter. Det resultatet är viktigt: rekommendera inte en destruktiv återställning som standardlösning på ett problem med användaråtkomst.
Vad du bör samla in innan du rapporterar problemet
Om en ny mapp som skapats via den aktuella ZimaOS-versionen fortfarande inte fungerar för en nyskapad medlem, ange ZimaOS-versionen, den delade sökvägen, medlemmens behörighetsinställning, klientens operativsystem, det exakta felet och om administratörsåtkomst fungerar. Spara även resultatet från id för det relevanta kontot och ls -ld endast för den berörda sökvägen.
De bevisen är mer användbara än ännu en bred ägarändring. Källtråden slutade med att communityn betraktade en reproduktion efter en ren installation som oväntad och värd en djupare utredning, inte med en verifierad lösning på en rad.
