Als een nieuw ZimaOS-lid in de deelinterface de machtiging Lezen en schrijven krijgt, maar nog steeds de melding ‘toegang geweigerd’ ontvangt, voer dan niet direct recursieve opdrachten voor het wijzigen van eigenaars uit op de hele opslagpool. In het oorspronkelijke discussieonderwerp uit maart 2026 werden verschillende theorieën over eigendom getest en werd een volledige reset uitgevoerd, maar de onderliggende oorzaak werd nog steeds niet bevestigd.
De meest duurzame methode voor probleemoplossing is om de machtigingslaag van ZimaOS/Samba te scheiden van de onderliggende Linux-laag voor eigendom. Reproduceer het probleem eerst in een kleine nieuwe map, vergelijk de toegang van de beheerder en het lid en inspecteer pas daarna het exacte hostpad.
De machtiging voor het lid leek correct in de gebruikersinterface
Het beheerdersaccount had toegang tot de gegevens, terwijl een nieuw aangemaakt account met de naam Andres lees-/schrijftoegang kreeg toegewezen, maar een machtigingsfout kreeg bij het openen van bestanden.
De huidige ZimaOS-versie ondersteunt Samba-machtigingen per gebruiker
De huidige ZimaOS-documentatie maakt onderscheid tussen toegang voor leden en gasten en stelt een beheerder in staat om een lid de machtiging Lezen of Lezen en schrijven te geven voor een Samba-share. Een lid met de machtiging Lezen en schrijven moet bestanden binnen de share kunnen downloaden, uploaden, hernoemen en verwijderen, op voorwaarde dat het onderliggende bestandssysteem toegankelijk is.
De huidige ZimaOS Samba-configuratie voor meerdere gebruikers is het juiste uitgangspunt voordat u shelloplossingen gebruikt die uit een ouder discussieonderwerp zijn gekopieerd.
Reproduceer het probleem in een gloednieuwe testmap
Maak via de huidige Bestanden-interface een kleine testmap aan op de beoogde gegevensschijf. Deel alleen die map met het nieuwe lid met de machtiging Lezen en schrijven en maak vanaf de client van het lid verbinding met de inloggegevens van dat lid.
Als de testmap werkt, maar gemigreerde of oudere mappen niet, houdt het probleem waarschijnlijk verband met die paden of hun eigendom. Als ook de gloednieuwe, via de gebruikersinterface gemaakte map niet werkt, is het probleem breder en moet het worden beschouwd als een mogelijk probleem met het account, Samba of de ZimaOS-machtigingen, en niet met verouderd bestandseigendom.
Gebruik Linux-eigenaarschap als diagnostisch signaal, niet als blinde oplossing
De thread onderzocht gebruikers-ID's en het eigenaarschap van mappen en stelde vast dat paden onder /DATA/.media eigendom waren van verschillende Linux-gebruikers en -groepen. Daardoor leek een mismatch in eigenaarschap aannemelijk voor gemigreerde gegevens.
chown bewerking leidde vervolgens tot veel fouten met de melding ‘Bewerking niet toegestaan’ in door toepassingen beheerde gegevens. Dat is een waarschuwing om niet één eigenaarschapsopdracht toe te passen op brede systeem- of AppData-mappenstructuren. Het recursief wijzigen van eigenaarschap kan containers of services beschadigen die specifieke UID's en GID's verwachten. De voorgestelde recursieve
Gebruik id, ls -lden een klein testbestand om het exacte probleemtraject te begrijpen. Pas geen wijzigingen toe op niet-gerelateerde toepassingsmappen.
Een fabrieksreset was geen bevestigde oplossing
Na het opnieuw formatteren en installeren meldde de auteur nog steeds fouten met de machtigingen van leden. Dat resultaat is belangrijk: raad een destructieve reset niet aan als normale oplossing voor een probleem met gebruikerstoegang.
Wat u moet verzamelen voordat u het probleem meldt
Als een nieuwe map die via de huidige ZimaOS is aangemaakt nog steeds niet toegankelijk is voor een nieuw aangemaakt lid, leg dan de ZimaOS-versie, het pad naar de gedeelde map, de machtigingsinstelling voor het lid, het besturingssysteem van de client, de exacte foutmelding en vast of toegang als beheerder wel werkt. Noteer ook de uitvoer van id voor het betreffende account en ls -ld alleen voor het getroffen pad.
Dat bewijs is nuttiger dan nog een brede wijziging van eigenaarschap. De bronthread eindigde ermee dat de community een reproductie na een schone installatie als onverwacht en nader onderzoek waardig beschouwde, niet met een geverifieerde oplossing in één regel.
