Could not Flash from sshfs mounted filesystem #1436

marcgott · 2017-05-16T07:16:17Z

1.0.0
kubuntu 16.10
neon-userltsedition-20170510-0019-amd64.iso
"The image is not accessible"

lurch · 2017-05-16T09:13:44Z

I once had this error myself on a SMB-mounted filesystem, but didn't bother reporting it as I didn't know if it was a situation that any users would run into - looks like I was wrong!

@jviotti The problem is that the network-share gets mounted by the user (using GVFS behind the scenes), and is then only accessible to the user who did the network-mount. So when the writer-process then elevates itself to root, it's then a different user, and can't access files from the network-mount.
Now that we've confirmed users are running into the problem themselves, I'll spend more time investigating it.

@marcgott As you may have already realised, a temporary workaround is to copy the file from sshfs to somewhere on your local computer, and Etcher will then be able to flash it correctly from there.

lurch · 2017-05-16T13:34:40Z

Done some more digging around on this... related links:
https://unix.stackexchange.com/questions/3606/root-user-denied-access-to-gvfs-in-rsnapshot
https://serverfault.com/questions/12162/directory-that-a-user-can-read-but-root-cant
(it seems that in newer versions of GVFS, the 'special directory' has moved from $HOME/.gvfs to /var/run/$(id -u)/gvfs )

I mounted a SMB share (as a normal user) on my Ubuntu 14.04 laptop, and when I do ls -l /var/run/1001 I see:

$ ls -l /run/user/1001/
total 8
drwx------ 2 andrew andrew  60 May 16 12:07 dconf
dr-x------ 3 andrew andrew   0 May 15 10:03 gvfs
drwx------ 2 andrew andrew  40 May 15 10:03 gvfs-burn
drwx------ 2 andrew andrew 120 May 15 10:03 keyring-utkuo6
drwx------ 2 andrew andrew  80 May 15 10:03 pulse
drwx------ 2 andrew andrew  40 May 16 09:45 unity
drwx------ 3 andrew andrew  60 May 15 10:03 upstart
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-dbus-bridge.2345.pid
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-file-bridge.2345.pid
lrwxrwxrwx 1 root   root    17 May 15 10:03 X11-display -> /tmp/.X11-unix/X0

However when I then try sudo ls -l /var/run/1001/ I see:

$ sudo ls -l /run/user/1001/
ls: cannot access /run/user/1001/gvfs: Permission denied
total 8
drwx------ 2 andrew andrew  60 May 16 12:07 dconf
d????????? ? ?      ?        ?            ? gvfs
drwx------ 2 andrew andrew  40 May 15 10:03 gvfs-burn
drwx------ 2 andrew andrew 120 May 15 10:03 keyring-utkuo6
drwx------ 2 andrew andrew  80 May 15 10:03 pulse
drwx------ 2 andrew andrew  40 May 16 09:45 unity
drwx------ 3 andrew andrew  60 May 15 10:03 upstart
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-dbus-bridge.2345.pid
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-file-bridge.2345.pid
lrwxrwxrwx 1 root   root    17 May 15 10:03 X11-display -> /tmp/.X11-unix/X0

i.e. anything inside the /var/run/1001/gvfs/ directory is totally inaccessible to any other user, even root.
This is what's actually inside that directory:

$ ls -l /run/user/1001/gvfs/
total 0
drwx------ 1 andrew andrew 0 Dec 17 13:34 smb-share:server=andynas.local,share=home

When I try selecting an image (in this case 2017-04-10-raspbian-jessie-lite.zip) from the home on andynas.local network share (which is how it's displayed in the file-selection dialog) it works okay, and Etcher is able to access the image (as my user) and compute the uncompressed image size as 1.3 GB. However after clicking Flash and entering my sudo-password, I then get an error dialog saying "Unable to access file The image /run/user/1001/gvfs/smb-share:server=andynas.local,share=home/DownloadStation/raspberrypi.org/2017-04-10-raspbian-jessie-lite.zip is not accessible". When I click OK to dismiss the (system) dialog, another (etcher) dialog pops up saying "Attention Oops, seems something went wrong. Retry".

The relevant lines from the DevTools console are:

Tue May 16 2017 14:06:11 GMT+0100 (BST) Flash ({"image":"/run/user/1001/gvfs/smb-share:server=andynas.local,share=home/DownloadStation/raspberrypi.org/2017-04-10-raspbian-jessie-lite.zip","drive":{"device":"/dev/sdb","description":"uSD UHS2 RDR","size":32026656768,"mountpoints":[],"raw":"/dev/sdb","protected":false,"system":false,"name":"/dev/sdb"},"uuid":"6f525026-0297-4c69-8478-0f7d12843204","unmountOnSuccess":true,"validateWriteOnSuccess":true})
/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 WRITER: Attempting to elevate

/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 WRITER: Running: /usr/lib/etcher-electron/etcher /usr/lib/etcher-electron/resources/app.asar/lib/child-writer/writer-proxy.js /usr/lib/etcher-electron/resources/app.asar /run/user/1001/gvfs/smb-share:server=andynas.local,share=home/DownloadStation/raspberrypi.org/2017-04-10-raspbian-jessie-lite.zip --drive /dev/sdb --unmount --check

/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 Tue May 16 2017 14:06:19 GMT+0100 (BST) Flash error ({"error":{"description":"The image 2017-04-10-raspbian-jessie-lite.zip is not accessible","report":false},"image":"/run/user/1001/gvfs/smb-share:server=andynas.local,share=home/DownloadStation/raspberrypi.org/2017-04-10-raspbian-jessie-lite.zip","drive":{"device":"/dev/sdb","description":"uSD UHS2 RDR","size":32026656768,"mountpoints":[],"raw":"/dev/sdb","protected":false,"system":false,"name":"/dev/sdb"},"uuid":"6f525026-0297-4c69-8478-0f7d12843204","unmountOnSuccess":true,"validateWriteOnSuccess":true})
/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 Tue May 16 2017 14:06:19 GMT+0100 (BST) Open modal ({"template":"./components/warning-modal/templates/warning-modal.tpl.html"})
/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 {"description":"The image /run/user/1001/gvfs/smb-share:server=andynas.local,share=home/DownloadStation/raspberrypi.org/2017-04-10-raspbian-jessie-lite.zip is not accessible","report":false}
console.(anonymous function) @ /usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51
/usr/lib/etcher-electron/resources/app.asar/node_modules/raven-js/dist/raven.js:51 Tue May 16 2017 14:22:03 GMT+0100 (BST) Modal accepted ({"value":false})

TBH I don't know if there's anything we can do about this - unless the pipage stuff that @jhermsmeier is currently working on would somehow allow the reader-part to read the file as the normal user, and then have the data streamed to the writer-part running as the root user? But I guess that's unlikely.

jviotti · 2017-05-16T15:07:46Z

Yeah, I don't think we can do much here. Can we at least throw a meaningful error describing that the selected file is not accessible by root, but only by the normal user, conflicting wth the fact that Etcher requires root permissions?

jviotti · 2017-05-16T15:09:57Z

Hm, wait. The image writer takes a readable stream of the image, and that is already created outside the module, so in theory it may be possible to somehow create it with different permissions. I'll be very busy in the following weeks, but I'd love to explore this possibility.

lurch · 2017-05-16T15:15:28Z

...and it's just occurred to me that when we add the "create backup" feature ( #266 ), we'll want to do the permissions the "other way around", i.e. read from the raw device as the root-user, but then write the output file as the normal-user ;)

jhermsmeier · 2017-05-16T23:36:55Z

read from the raw device as the root-user, but then write the output file as the normal-user

For raw reads from a device you don't need to be root (or elevated) on any OS, afaik – so that shouldn't give us complications

jhermsmeier · 2017-05-16T23:40:15Z

so in theory it may be possible to somehow create it with different permissions

Shouldn't we be able to elevate a process while keeping the uid of the normal user (think the equivalent of sudo -u)?

lurch · 2017-05-17T00:31:31Z

AFAIK you're either running as the root user (which allows us to write to the raw device), or you're running as the normal user (needed in this case to read from the user-level GVFS network share) - I don't think a single process can be running in both modes (?). I think you'd need to use IPC (e.g. a pipe) to communicate between a root-level process and a separate user-level process. However a root-level process can launch a user-level process, as seen here ;-) (thanks for the sudo -u tip 👍 )

$ sudo sudo -u andrew ls -l /run/user/1001/
total 8
drwx------ 2 andrew andrew  60 May 17 00:39 dconf
dr-x------ 3 andrew andrew   0 May 15 10:03 gvfs
drwx------ 2 andrew andrew  40 May 15 10:03 gvfs-burn
drwx------ 2 andrew andrew 120 May 15 10:03 keyring-utkuo6
drwx------ 2 andrew andrew  80 May 15 10:03 pulse
drwx------ 2 andrew andrew  40 May 17 01:11 unity
drwx------ 3 andrew andrew  60 May 15 10:03 upstart
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-dbus-bridge.2345.pid
-rw-r--r-- 1 andrew andrew   5 May 15 10:03 upstart-file-bridge.2345.pid
lrwxrwxrwx 1 root   root    17 May 15 10:03 X11-display -> /tmp/.X11-unix/X0

(here I believe there's effectively three processes - the outer-level sudo to elevate to root, the inner sudo (being run by root) to run a process as the andrew user, and the ls -l which is the command that finally gets run by andrew)

Pinging @petrosagg in case he has any clever ideas ;-) (or in case I'm horribly wrong)

petrosagg · 2017-07-02T07:25:32Z

@lurch @jviotti @jhermsmeier A potential solution to this problem would be to open the source file before elevation and passing the file descriptor to the elevated process. This way all the checks will have already been done before elevation and the root process should be able to read as normal.

lurch · 2017-07-03T12:33:01Z

Is it safe to pass file-descriptors between processes? Given that the elevated and non-elevated parts communicate via IPC, I guess you'd need to serialise and then deserialise the fd?

Hmm, I found https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux-socket/ which seems to be *nix-specific, so I dunno if that'd work on Windows?

lurch · 2018-11-27T09:31:24Z

Hmmm, why was this closed?

imrehg · 2019-08-14T08:59:09Z

@thundron @jviotti hitting the same thing, may we reopen this? And possibly try the suggestion from @petrosagg just above in this thread?

jellyfish-bot · 2020-05-14T07:20:44Z

[anujdeshpande] This issue has attached support thread https://jel.ly.fish/#/17864624-3903-4e52-b792-cad2b5931323

fake-name · 2022-05-19T10:18:16Z

At minimum, there really, REALLY needs to be some sort of warning if you're trying to flash using an image from a network drive.

marcgott changed the title ~~Could not Flash from sshfs drive~~ Could not Flash from sshfs mounted filesystem May 16, 2017

lurch added component:sdk platform:linux type:bug labels May 16, 2017

lurch self-assigned this May 16, 2017

jviotti added this to the Backlog milestone Dec 5, 2017

lurch mentioned this issue Feb 26, 2018

Improve file browser EACCES error message #2075

Closed

lurch removed their assignment Mar 1, 2018

lurch mentioned this issue Apr 25, 2018

Does not work with Windows' "Mapped network drives" #2278

Closed

jviotti closed this as completed Oct 15, 2018

lurch mentioned this issue Jul 21, 2019

Unable to open an image from the mapped network drive #2858

Open

lurch mentioned this issue Apr 20, 2020

Issue of flashing image located on NAS (WD Mycloud) #3122

Closed

lurch mentioned this issue May 20, 2020

Empty error dialog shown if .img is on a network share raspberrypi/rpi-imager#65

Closed

snyk-bot mentioned this issue Sep 15, 2021

[Snyk] Fix for 1 vulnerabilities enterstudio/etcher#31

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Could not Flash from sshfs mounted filesystem #1436

Could not Flash from sshfs mounted filesystem #1436

marcgott commented May 16, 2017

lurch commented May 16, 2017

lurch commented May 16, 2017

jviotti commented May 16, 2017

jviotti commented May 16, 2017

lurch commented May 16, 2017

jhermsmeier commented May 16, 2017

jhermsmeier commented May 16, 2017

lurch commented May 17, 2017

petrosagg commented Jul 2, 2017

lurch commented Jul 3, 2017

lurch commented Nov 27, 2018

imrehg commented Aug 14, 2019

jellyfish-bot commented May 14, 2020

fake-name commented May 19, 2022

Could not Flash from sshfs mounted filesystem #1436

Could not Flash from sshfs mounted filesystem #1436

Comments

marcgott commented May 16, 2017

lurch commented May 16, 2017

lurch commented May 16, 2017

jviotti commented May 16, 2017

jviotti commented May 16, 2017

lurch commented May 16, 2017

jhermsmeier commented May 16, 2017

jhermsmeier commented May 16, 2017

lurch commented May 17, 2017

petrosagg commented Jul 2, 2017

lurch commented Jul 3, 2017

lurch commented Nov 27, 2018

imrehg commented Aug 14, 2019

jellyfish-bot commented May 14, 2020

fake-name commented May 19, 2022