"snap" programma's kunnen niet bij NFS-share

[Josefien]

Mijn vraag
...
Programma's die via "snap" zijn geïnstalleerd kunnen geen bestanden openen die op een gekoppelde NFS-share staan (Permission denied), ondanks dat de toegangsrechten goed staan In dit geval gaat het om Leafpad en KompoZer, beide niet in de normale repositories van Ubuntu 20.04 te vinden, maar wel te installeren met "snap install".

Los daarvan starten ze ook erg traag op. De simpele Leafpad heeft 4-5 secondes nodig om op te starten terwijl een normale installatie vrijwel instant start


Relevante software en hardware die ik gebruik
...
Ubuntu MATE 20.04


Wat ik al gevonden of geprobeerd heb
...
Voor Leafpad heb ik al een oplossing gevonden in de zin van de .deb van een oudere Ubuntu te installeren. Dat werkt prima en ik heb weer een snelle Leafpad die alle bestanden kan openen binnen het bereik v/d gebruiker

Voor KompoZer werkt dat echter niet, er zijn afhankelijke pakketten (multiarch-support) die niet meer beschikbaar is voor 20.04

Via Google lijkt het wel een "feature" van "snap" dat je programma's niet op een NFS-share kunnen komen, wat het nut ervan is weet ik niet, maar ik heb geen oplossing gevonden

Hoe kan ik nu KompoZer gebruiken met bestanden op een NFS-share? Desnoods een versie die ik op een andere manier kan installeren?

P.s. De bestanden vanaf de NFS naar lokaal en terug kopiëren is geen optie.

[goarilla]

Ik vermoed dat snaps in een soort jail/chroot/namespace zitten.
Misschien kan je je NFS mounts mount-binden in een directory die wel native aanwezig is in je snap.
Maar ik ben hier vrij aan het gissen.

[Brahiewahiewa]

Zie https://askubuntu.com/que...e-snaps-access-to-somedir

Je moet je NFS share dus mounten in één van de hardcoded shares

[Josefien]

De share is nu gemount in /media/nfs/network-homes.

Het is niet de bedoeling dat de NFS in de home-directory gemount wordt. Er is wel een symlink in the home-directory, maar ook dat werkt niet.

Een applicatie gaat toch niet voortaan bepalen waar ik mijn bestandssystemen moet mouten?

[Voor 19% gewijzigd door Josefien op 12-07-2020 14:53]

[Brahiewahiewa]

Josefien schreef op zondag 12 juli 2020 @ 14:53:
...
Een applicatie gaat toch niet voortaan bepalen waar ik mijn bestandssystemen moet mouten?

In het geval van snap dus wel

[Josefien]

Wat is het nut daarvan?

Ik wil dus van die snaps af Da's dan duidelijk. Het is dus èn traag èn beperkt.

KompoZer is nu nog het enige wat als snap wordt gebruikt. Wat zijn de alternatieve manieren om dat programma onder 20.04 te installeren, waarbij het gewoon werkt zoals onder 16.04?

[Voor 6% gewijzigd door Josefien op 12-07-2020 15:10]

[Brahiewahiewa]

Josefien schreef op zondag 12 juli 2020 @ 15:09:
... Wat zijn de alternatieve manieren om dat programma onder 20.04 te installeren, waarbij het gewoon werkt zoals onder 16.04?

Gewoon de tarball uitpakken en zelf de config file(s) invullen?

[3dmaster]

Beetje off topic antwoord misschien:
Wellicht is het tijd om uit te wijken naar een andere distro. Debian of Arch. Als de Arch setup je wat te ingewikkeld is -> Manjaro. Ik ben 2 jaar geleden voor mijn desktop geswitcht naar Arch en nog geen seconde spijt.

[amx]

Het idee achter een snap kan het beste worden bekeken in de introductievideo van Mark Shuttleworth, die kan het veel beter uitleggen.

Redenen waarom een snap handig is en isolatie van de rest van het bestandssysteem wenselijk is, kan de eenvoud van installatie zijn en eenvoudige beheerbaarheid (via snapshots), en het fungeren als een container, waardoor het automatisch minder kwestbaar is voor privilege escalation.

Het idee is een beetje dat je een applicatie als soort van container start die reeds volledig geconfigureerd is. Met een enkel commando maak je een snapshot van de huidige instellingen. Als je de applicatie wil verwijderen, worden de snapshots bewaard, zodat je je oude instellingen terug kan krijgen, tenzij je de paramater --purge toevoegt.

Kortom: je moet op zoek of deze apps in een use case van jouw systeem passen, of de alternatieven bekijken.

[goarilla]

En een bind mount in een directory in je home ipv een symlink ?
https://unix.stackexchang...8590/what-is-a-bind-mount

Misschien kan je KompoZer zelf compileren.
Voor compileerinspiratie zou ik gaan kijken naar de laatste debian of ubuntu src package die wel een zelf-gecompileerde KompoZer had:
http://old-releases.ubunt...pool/universe/k/kompozer/

Je kan een versie voor een oudere ubuntu proberen maar dat raad ik eigenlijk nooit aan:
(https://help.ubuntu.com/community/InstallKompozer)

[Josefien]

De bin-file in de tarball start niet. Er zitten wel scripts in waarvan mogelijk een installatiescript, maar allemaal zonder handleiding. Daar moet ik later eens verder naar kijken.

Een oudere Ubuntu-package werkt zoals geschreven niet voor KompoZer. Één van de afhankelijke packages heeft multiarch-support nodig en dat pakket is niet beschikbaar in 20.04.

Voor een andere distributie ben ik nooit gegaan omdat de meeste tutorials op internet voor Ubuntu zijn. En ook die PPA's voor van alles en nog wat werkt alleen makkelijk onder Ubuntu. Plus sommige distro's die ik geprobeerd heb (zoals Fedora) hebben tergend langzame package-managers. Of ze missen weer restricted-software zoals makkelijk te installeren Windows-basisfonts of Adobe Flash plugin.

Een bind-mount moet uiteindelijk dus voor elk gebruikersaccount. Zo onhandig.

Als dat trouwens de enige oplossing is, dan kan ik net zo goed de PortableApps-versie voor Windows pakken en dan via Wine gebruiken. Want dat werkt wel. Alleen vind ik het een beetje triest als er wel een native Linux-versie bestaat...

[Freeaqingme]

Ik sluit me aan bij @3dmaster. Na 15 jaar ubuntu gebruikt te hebben waren de snaps voor mij reden om naar Debian te switchen.

Het idee van snaps is op zich prima, maar de uitvoering; not so much. Applicaties starten traag, je moet volgens een voorgeschreven manier je directories/mounts inrichten (en zelfs dan werkt het niet even leuk samen; bijv. firefox die bestanden in /tmp/.mozilla/ opslaat, libreoffice die daarvan niet mag lezen), je hebt 0 controle over wanneer er een update wordt uitgevoerd en het moet per se via de repo van Canonical.

Mijn suggestie zou zijn om te kijken of je het nu voor deze ene specifieke applicatie kan fixen, en langzaam aan nadenken over een andere distro. Of dit in ieder geval bij je distro aankaarten, Mint is al gestopt met het supporten van snaps.

[woutervb2]

Volgens mij is er hier een misverstand aan de gang.

Het is niet zo dat snaps dicteren waar je bestanden wel of niet kunt plaatsen. Het is wel zo dat er security policies aan snaps gekoppeld zijn, die bepalen waar een snap wel of niet bij kan.

Waar het nu mis gaat, is dat de auteur van deze snap er blijkbaar voor gekozen heeft om beperkte toegang tot het filesysteem aan te vragen in zijn/ haar snap.

Dus de beperking komt door de auteur van de snap, de snapd op het systeem doet precies wat het gevraagd wordt, dus daar kan het systeem verder niets aan doen.