Open diemkae opened 4 years ago
Did you connect your snap-app's to the removable-media
interface ?
Most of snap need it, but they don't all provide it by default.
On recent gnome environment you can do that through system settings / applications.
With removable-media
enabled, a snap can access /media, /mnt, /run/media. So your CiFS or NFS shares must be mounted into one of those places. None else.
A snap has no straight access to the / root system partition and no access to hidden files ( files/folders beginning with a . dot ).
So, anyone that has automounted NFS home directories is just SOL???
Seems to me like a very short-sighted decision by the backward-compatibility group of the snapd design team!
And the sneaky way they suppress installation of a non-snap version of gimp or other packages is just downright nasty!
I've been committed to ubuntu since 10.04 LTS, but this new imperialistic, dictatorial attitude of the "snap" folks is starting to feel like the last straw with respect to using ubuntu on any of the systems here There are alternatives!
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Mon, Nov 2, 2020 at 3:49 PM Cœur Noir notifications@github.com wrote:
Did you connect your snap-app's to the removable-media interface ?
Most of snap need it, but they don't all provide it by default.
On recent gnome environment you can do that through system settings / applications.
With removable-media enabled, a snap can access /media, /mnt, /run/media. So your CiFS or NFS shares must be mounted into one of those places. None else.
A snap has no straight access to the / root system partition and no access to hidden files ( files/folders beginning with a . dot ).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-720716287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXZHWXOAY4ZR26WBID3SN4LNLANCNFSM4QL7UAUQ .
I did not mention it but most of snap app's have access to /home by default.
To sum it up, snap can see mounting points when they are in : ⋅ /home ⋅ /media ⋅ /mnt ⋅ /run/media
But you seem right regarding NFS ( or SMB ) : ⋅ https://askubuntu.com/questions/1220209/snap-with-nfs-shares ⋅ https://forum.snapcraft.io/t/difficulty-viewing-mounted-fileystems-via-samba-nfs-gvfs-interface/14680
( sorry, English is not my native language, what does SOL stand for ? )
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Tue, Nov 3, 2020 at 10:11 AM Cœur Noir notifications@github.com wrote:
I did not mention it but most of snap app's have access to /home by default.
To sum it up, snap can see mounting points when they are in : ⋅ /home ⋅ /media ⋅ /mnt ⋅ /run/media
But you seem right regarding NFS ( or SMB ) : ⋅ https://askubuntu.com/questions/1220209/snap-with-nfs-shares ⋅ #121 https://github.com/snapcrafters/gimp/issues/121 ⋅ https://forum.snapcraft.io/t/difficulty-viewing-mounted-fileystems-via-samba-nfs-gvfs-interface/14680
( sorry, English is not my native language, what does SOL stand for ? )
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-721188221, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXX6YMFCUIQNNVKIIH2LSOAMRLANCNFSM4QL7UAUQ .
No problem, happy to learn ;-)
I can see here : https://forum.snapcraft.io/t/snaps-and-nfs-home/438 or https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784774 maybe some hope in case of NFS /home.
Seems it's not ( only ) the removable-media interface that's needed, but network interface : https://snapcraft.io/docs/supported-interfaces
Thanks for the link, but those "fixes" seem just to add to the complexity, and thus diminish the reliability, of all things "snap" ... maybe I'll go back 18.04 and get rid of all the snap-crap until I can decide which non-ubuntu distro to use. There seems to be a sad user-unfriendly trend in ubuntu. For example, I really liked Unity but that went away. Happily, most of the things I liked in Unity are in the std 20.04, but this snap complexity really seems to go against the grain, against the spirit of Unix, IMHO, for power users.
What exactly are the advantages of snap anyway?
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Tue, Nov 3, 2020 at 10:23 AM Cœur Noir notifications@github.com wrote:
No problem, happy to learn ;-)
I can see here https://forum.snapcraft.io/t/snaps-and-nfs-home/438 maybe some hope in case of NFS /home.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-721195913, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXYD2WW5SJMU4PBREBTSOAOABANCNFSM4QL7UAUQ .
In my situation, it's not actually that /home is automounted NFS, but there are several other important NFS mounts like /export mounted from a FreeNAS file server which I installed to better secure much of our data).
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Tue, Nov 3, 2020 at 10:48 AM Knight, Dave diemkae@gmail.com wrote:
Thanks for the link, but those "fixes" seem just to add to the complexity, and thus diminish the reliability, of all things "snap" ... maybe I'll go back 18.04 and get rid of all the snap-crap until I can decide which non-ubuntu distro to use. There seems to be a sad user-unfriendly trend in ubuntu. For example, I really liked Unity but that went away. Happily, most of the things I liked in Unity are in the std 20.04, but this snap complexity really seems to go against the grain, against the spirit of Unix, IMHO, for power users.
What exactly are the advantages of snap anyway?
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Tue, Nov 3, 2020 at 10:23 AM Cœur Noir notifications@github.com wrote:
No problem, happy to learn ;-)
I can see here https://forum.snapcraft.io/t/snaps-and-nfs-home/438 maybe some hope in case of NFS /home.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-721195913, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXYD2WW5SJMU4PBREBTSOAOABANCNFSM4QL7UAUQ .
try
df -x squashfs -x tmpfs
Well for that matter ( mounts location ) snap only follows « classic » linux folder tree where /home
, /media
and /mnt
are the de facto places for user-oriented mounts.
Also note for the moment, you may also bind folders from one place to ( eventually many ) other ( mount --bind
or through fstab
) to make them available to snap.
For the moment → as it goes a bit against designed snap safety concept, I assume it may become impossible ( ? ).
Thanks for the suggestions, but they all seem rather temporary, i.e. "For the moment" . I like longer term, robust solutions which, BTW is why I embraced the LTS distros of ubuntu in the first place.
"For the moment", I have chosen to purge all the snap stuff from this system (20.04) and, in the case of the "official" chromium, which insists on reinstallation snap, I have firefox, opera and a non-snap version of chromium as options which do not.
Maybe snap/snapd has good intentions, but when it intentionally breaks stuff that has been working literally forever in Linux and in Unix-like systems in general, it loses it usefulness as far as I'm concerned!
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Tue, Nov 3, 2020 at 12:07 PM Cœur Noir notifications@github.com wrote:
try df -x squashfs -x tmpfs
Well for that matter ( mounts location ) snap only follows « classic » linux folder tree where /home, /media and /mnt are the de facto places for user-oriented mounts.
Also note for the moment, you may also bind folders from one place to ( eventually many ) other ( mount --bind or through fstab ) to make them available to snap. For the moment → as it goes a bit against designed snap safety concept, I assume it may become impossible ( ? ).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-721259426, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXX42AIEPMYZO5DTMAFLSOA2EZANCNFSM4QL7UAUQ .
It could also just be a matter of « where » are your nfs shares mounted. It should be ok if they are mounted somewhere in : ⋅ /home ⋅ /media ⋅ /mnt ⋅ /run/media
Anywhere else it won't work, so don't create mounting points like :
⋅ /data
⋅ /export → change this for /media/export
or /mnt/export
if possible ?
⋅ /nfs
⋅ …
The purpose here is safety. By strictly following linux-folder-tree recommendations, snap reduce interactions between applications and system. Can be seen as an advantage in some contexts.
For the moment → as it goes a bit against designed snap safety concept, I assume it may become impossible ( ? ). It's really an assumption of mine, here. As things move quite fast in snap realm. For example, I thought snap never had access to hidden files, they may actually read hidden files, but won't write to them ( unless they are stored or bound in ~/snap/app/.somewhere )
And the sneaky way they suppress installation of a non-snap version of gimp or other packages is just downright nasty! I may agree here, but other ways to install things were not suppressed at all. Just a bit pushed away at first sight, the nasty bit. « app'store » tended to show snap in priority but it's no longer the case, now you can chose « the source for package » ( APT/deb, snapstore, flatpak ).
Synaptic or gnome-package-kit have never gone away, neither command like sudo apt install gimp
PPA are still a thing too, have an eye to https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/gimp if you're looking for an up-to-date .deb for gimp ;-)
The only open-source package distributed by Ubuntu as a snap is chromium web browser. All others may be found in .deb / flatpak / snap / AppImage, depending on community effort and dev's team to package.
Non-free/proprietary app's may be found only as snap, depending mostly on their editors.
Thanks for you insights and additional suggestions. I have a developer's build of chrome-linux which works fine without any dependencies on snap.
I had to ditch "opera" browser because there seemed to be no way to disconnect it from google as its default search engine - one can change it, to duckduckgo, for example, butthe change is not permanent.
For the majority of Linux users I know (power users all) the complications of snap in the name of "safety" (i.e. "it's for your own good, you know") is anathema to those who embraced the founding principles of Unix.
If y'all keep moving in this direction, I know at least a few Ubuntu users who will go elsewhere.
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Thu, Nov 5, 2020 at 1:38 PM Cœur Noir notifications@github.com wrote:
And the sneaky way they suppress installation of a non-snap version of gimp or other packages is just downright nasty! I may agree here, but other ways to install things were not suppressed at all. Just a bit pushed away at first sight, the nasty bit. « app'store » tended to show snap in priority but it's no longer the case, now you can chose « the source for package » ( APT/deb, snapstore, flatpak ).
Synaptic or gnome-package-kit have never gone away, neither command like sudo apt install gimp
PPA are still a thing too, have an eye to https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/gimp if you're looking for an up-to-date .deb for gimp ;-)
The only open-source package distributed by Ubuntu as a snap is chromium web browser. All others may be found in .deb / flatpak / snap / AppImage, depending on community effort and dev's team to package.
Non-free/proprietary app's may be found only as snap, depending mostly on their editors.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-722563725, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXZK3DK6RMNYF36B4R3SOLWJHANCNFSM4QL7UAUQ .
Yes, and chromium is the thing that I cite as "nasty". Specifically, when I:
sudo apt install chromium-browser
I get:
dmk@del1:~$ sudo apt install chromium-browser [sudo] password for dmk: Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: snapd The following NEW packages will be installed: chromium-browser snapd 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 48.3 kB/28.5 MB of archives. After this operation, 126 MB of additional disk space will be used. Do you want to continue? [Y/n]
I WAS using chromium-browser without snapd and the snap "conspiracy" has subverted that..
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Thu, Nov 5, 2020 at 8:38 PM Knight, Dave diemkae@gmail.com wrote:
Thanks for you insights and additional suggestions. I have a developer's build of chrome-linux which works fine without any dependencies on snap.
I had to ditch "opera" browser because there seemed to be no way to disconnect it from google as its default search engine - one can change it, to duckduckgo, for example, butthe change is not permanent.
For the majority of Linux users I know (power users all) the complications of snap in the name of "safety" (i.e. "it's for your own good, you know") is anathema to those who embraced the founding principles of Unix.
If y'all keep moving in this direction, I know at least a few Ubuntu users who will go elsewhere.
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Thu, Nov 5, 2020 at 1:38 PM Cœur Noir notifications@github.com wrote:
And the sneaky way they suppress installation of a non-snap version of gimp or other packages is just downright nasty! I may agree here, but other ways to install things were not suppressed at all. Just a bit pushed away at first sight, the nasty bit. « app'store » tended to show snap in priority but it's no longer the case, now you can chose « the source for package » ( APT/deb, snapstore, flatpak ).
Synaptic or gnome-package-kit have never gone away, neither command like sudo apt install gimp
PPA are still a thing too, have an eye to https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/gimp if you're looking for an up-to-date .deb for gimp ;-)
The only open-source package distributed by Ubuntu as a snap is chromium web browser. All others may be found in .deb / flatpak / snap / AppImage, depending on community effort and dev's team to package.
Non-free/proprietary app's may be found only as snap, depending mostly on their editors.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-722563725, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXZK3DK6RMNYF36B4R3SOLWJHANCNFSM4QL7UAUQ .
Here is not the place for our opinions about snap and other things.
Back to topic : gimp or vlc as snap seem to have no access to your nfs share.
Did you try to mount your nfs share inside /home/export
or /media/export
or /mnt/export
instead of /export
?
As far as I understand, that should be enough to solve your problem, given
⋅ both snap are connected to removable-media and network interfaces,
⋅ your $USER has necessary rights and permissions to access /…/export
In other words
⋅ as long as you target /export
it won't work, by design so it's not a bug,
⋅ if you manage to change that mounting point from /export
to /{home|media|mnt}/export
and the problem still occurs, then we probably still have a bug.
I'm not a dev' neither very used to nfs but in my daily usage at work and at home I have no problems with gimp-snap accessing many partitions or removable drives and network resources ( samba ).
Agreed. Sorry for wandering off into the technical discussion weeds.
Yes, I can mount the NFS filesystem as /media/export or whatever and that works, and I can make /export a symlink to /media/export and many of the scripts etc that depended on the NFS filesystem mounted as /export worked, but others did not and operational access to the NFS files in snap apps was less straightforward because /export was not listed among the "accessible" filesystems (i.e. in "open files" selection, click Other Locations->Computer) ... i.e. "backward compatibility" was broken for snap'd apps and some of my more complex system admin scripts. I tried some of the solutions you suggested, but users here complained mightily.
Of course multiple "workarounds" are possible, but for me, as both a developer and local system admin responsible for a dozen Ubuntu hosts, a handful of raspberry pi hosts and a FreeNAS file server where the exported NFS filesystems and the /BriefCase revision control and release management server are hosted, the time it takes to develop those workarounds takes away from the time I can devote to doing my actual job. At this time, it's easier and faster to ditch snapd and find non-snap versions of the snapd apps.
Thanks for your time and suggestions. You have been very helpful and patient with wanderings.
Have a great day!
Dave
--
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Sat, Nov 7, 2020 at 1:08 PM Cœur Noir notifications@github.com wrote:
Here is not the place for our opinions about snap and other things.
Back to topic : gimp or vlc as snap seem to have no access to your nfs share.
Did you try to mount your nfs share inside /home/export or /media/export or /mnt/export instead of /export ?
As far as I understand, that should be enough to solve your problem, given ⋅ both snap are connected to removable-media and network interfaces, ⋅ your $USER has necessary rights and permissions to access /…/export
In other words ⋅ as long as you target /export it won't work, by design so it's not a bug, ⋅ if you manage to change that mounting point from /export to /{home|media|mnt}/export and the problem still occurs, then we probably still have a bug.
I'm not a dev' neither very used to nfs but in my daily usage at work and at home I have no problems with gimp-snap accessing many partitions or removable drives and network resources ( samba ).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-723476342, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXX4UDT2XGM4ZPMYTTKDSOWEIVANCNFSM4QL7UAUQ .
the time it takes to develop those workarounds takes away from the time I can devote to doing my actual job I'm probably not at the same scale but I can relate and unfortunately sometimes it's easier and faster to ditch snapd and find non-snap versions of the snapd apps. is the only way.
Indeed. FWIW, you seem to be more understanding than your name (pseudonym?) suggests.
In your time of need, may your piece be with you!
The trouble with many of today's college graduates is not that they're ignorant, it's that they've been taught so much that just isn't so!
(with apologies to
Ronald Reagan).
On Sat, Nov 14, 2020 at 8:40 PM Cœur Noir notifications@github.com wrote:
the time it takes to develop those workarounds takes away from the time I can devote to doing my actual job I'm probably not at the same scale but I can relate and unfortunately sometimes
it's easier and faster to ditch snapd and find non-snap versions of the snapd apps. is the only way.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snapcrafters/gimp/issues/121#issuecomment-727292959, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRXXXZKN7RL6GRILELBI7LSP4WRVANCNFSM4QL7UAUQ .
Under Ubuntu 20.04 LTS the snap-installed gimp -2.10.20 (/snap/bin/gimp) cannot open NFS or CIFS files/paths that are fully accessible to other apps. After removing the snap version of gimp and installing the non-snap version of gimp 2.10.20 (with sudo apt install gimp) /usr/bin/gimp can access NFS/CIFS files/paths without a problem.
This same issue arises with the snap-installed vlc application:
dmk@del1:~$ cd /export dmk@del1:/export$ ls home home1 miscSave perfectlyFlat.jpg root rsync Stage vboxHD vbShare dmk@del1:/export$ vlc perfectlyFlat.jpg cannot open path of the current working directory: Permission denied dmk@del1:/export$ which vlc /snap/bin/vlc dmk@del1:/export$ sudo snap info vlc [sudo] password for dmk: name: vlc summary: The ultimate media player publisher: VideoLAN✓ store-url: https://snapcraft.io/vlc contact: https://www.videolan.org/support/ license: unset description: | VLC is the VideoLAN project's media player.
Completely open source and privacy-friendly, it plays every multimedia file and streams.
It notably plays MKV, MP4, MPEG, MPEG-2, MPEG-4, DivX, MOV, WMV, QuickTime, WebM, FLAC, MP3, Ogg/Vorbis files, BluRays, DVDs, VCDs, podcasts, and multimedia streams from various network sources. It supports subtitles, closed captions and is translated in numerous languages. commands:
... //nas3/nas3.dmk 4447111099 53666017 4393445082 2% /media/nas.dmk nas3:/mnt/pool1/nas2Exports 4760347776 366902656 4393445120 8% /export
and the snap-installed arduino: dmk@del1:/export/home/dmk/Arduino%/newGeiger$ which arduino /snap/bin/arduino dmk@del1:/export/home/dmk/Arduino%/newGeiger$ arduino newGeiger.ino cannot open path of the current working directory: Permission denied dmk@del1:/export/home/dmk/Arduino%/newGeiger$ sudo snap info arduino name: arduino summary: Write code and upload it to your Arduino-compatible board. publisher: Merlijn Sebrechts store-url: https://snapcraft.io/arduino contact: https://github.com/snapcrafters/arduino/issues license: GPL-2.0 description: | Arduino is an open-source physical computing platform based on a simple I/O board and a development environment that implements the Processing/Wiring language. Arduino can be used to develop stand-alone interactive objects or can be connected to software on your computer (e.g. Flash, Processing and MaxMSP). The boards can be assembled by hand or purchased preassembled at https://arduino.cc
Setup
In order to upload code an arduino board over USB, you need to add your user to the
dialout
group. Open a terminal window, run the following command and reboot your computer.Now restart your computer and you're good to go!
Python 3 support
This version of Arduino IDE runs in a sandbox for improved security and stability. As a result, it does not have access to the Python libraries on your device.
Python 3 and the
serial
library are installed inside of the sandbox so they can be used by plugins. If a plugin needs additional Python 3 libraries, you can install them using thearduino.pip
command. For example, the following command installs therequests
library inside of the sandbox so the Arduino IDE can use it.Python 2 is currently not supported in this package because it reached end of life on January 1st 2020. If you have hardware that requires Python 2 support, please let us know.
Are you having issues?
Let us know by creating a new issue here: https://github.com/snapcrafters/arduino/issues commands:
latest/beta: ↑
latest/edge: 1.8.13 2020-07-07 (44) 148MB - installed: 1.8.13 (41) 148MB - dmk@del1:/export/home/dmk/Arduino%/newGeiger$
suggesting that this is a genreic problem with apps distributed via snap.