Bug #946

App Installs Fail (Permissions Error on /tmp/amahi-download-cache/)

Added by fabersa almost 9 years ago. Updated almost 9 years ago.

App Install
Target version:
Start date:
Due date:
% Done:



Server Setup:
Amahi install on fresh Ubuntu 12.04 installation (computer only used as Amahi server)

While attempting to install "Ampache" received an error (from the amahi-app-installer.log:
Permission denied - /tmp/amahi-download-cache/60f44983c3dfed92cc249fef24ba5685f69cb38c (Errno::EACCES)

Entire amahi-app-installer.log:

Temporary Resolution
I was able to install the app after running the following command:
sudo chmod 777 /tmp/amahi-download-cache

IRC #Amahi Chat w/ CPG:
[17:33] <fabersa> anybody seeing permission errors on /tmp/amahi-download-cache in Ubuntu? One of my installs was hung up until I did a chmod 777 on that directory
[18:03] <+cpg> fabersa: hmmm
[18:03] <+cpg> could be a bug potentially
[18:03] <+cpg> however, it's created the first time it's needed
[18:03] <+cpg> byt the same process that needs it, so it seems a bit odd
[18:03] <+cpg> how did this install originate?
[18:06] <fabersa> via http://hda. I tried it on a client, then on the server itself. install log:
[18:06] <fabersa> the first entry in the logis the failed install
[18:06] <fabersa> the second is afte the chmod777
[18:07] <fabersa> I don't mind filing a bug... just didn't want to if it was a fluke
[18:07] <fabersa> or a known problem already
[18:42] <+cpg> fabersa: ls -la /tmp/amahi-download-cache | pastebinit
[19:30] <fabersa> sorry took so long... wife wanted me to eat dinner... lame.
[19:31] <+cpg> fabersa: yes, there is an issue. it's own by root.
[19:32] <+cpg> this is definitely not standard. did you mess with it
[19:32] <fabersa> nope.... just installed some things from the apps page in the dashboard.
[19:35] <fabersa> I did have to install gparted... ffmpeg and imagemagick for gallery3, and followed instructions to "Mount Shares Locally".... but other thatn that.... no installs otherthan from the dashboard
[19:37] <fabersa> I installed two apps today. The first was Subsonic. It installedno problem. A few hours later I installed Ampache. The Ampache install is where I had trouble. So maybe something with the Subsonic install messed with the permissions?
[19:38] <+cpg> yeah, but how did it come to be owned by root???
[19:38] <+cpg> where did that drive come from?
[19:39] <fabersa> what do you mean exactly?
[19:43] <+cpg> looking at the code … what i see is that this should not be owned by root
[19:43] <+cpg> and we have dozens of people installing apps
[19:44] <+cpg> with permissions issues, NOONE would be able to install apps
[19:44] <+cpg> so until i can test more on a clean system , this seem very odd and a one-off
[19:44] <+cpg> know what i mean?
[19:45] <fabersa> yeah... could be. I just posted the whole installer log here:
[19:46] <fabersa> looking at line 34 - 50 explains why OpenVPN wouldn't work.
[19:47] <fabersa> So looks like i just had a random permission thing. Maybe i did something, but i don't think so.
[19:47] <fabersa> who should own it? user_name:users ?
[19:48] <+cpg> alternatively … there could be a one off bug
[19:48] <+cpg> let me review
[19:49] <+cpg> it COULD be due to one app install script running amahi-download in an elevated environment
[19:49] <+cpg> that's the only thing i can think of
[19:50] <fabersa> Do you want me to file a bug and put all the pastebin references in it?
[19:57] <+cpg> fabersa: that would be awesome
[19:57] <+cpg> fabersa: u are 100% there is nothing funky here? like you moved the drive or messed as sudo or something?
[19:58] <+cpg> just sayin'
[19:58] <fabersa> nope... nothing funky at all :)
[19:59] <+cpg> kk
[19:59] <+cpg> then a bug would be perfect
[19:59] <+cpg> here is my concern
[19:59] <+cpg> initially the directory does not exist
[20:00] <+cpg> then one app does an amahi-download inside an elevated script, which SHOULD NOT DO
[20:00] <+cpg> then the directory is created as root
[20:00] <+cpg> other apps get stuck
[20:01] <+cpg> here in the log there is no possibility of this happenning tho
[20:01] <+cpg> unless /tmp was deleted in between app installs
[20:01] <+cpg> can you add that to the bug, please fabersa ?
[20:02] <fabersa> Yes... I'll paste this whole conversation. I just went through all my command line history... don't see anything that would change ownership of the temporary cache. I'll let you know the bug number.
[20:16] <+cpg> fabersa: great, thanks!


#1 Updated by fabersa almost 9 years ago

FYI... a history of all the commands EVER manually used on this machine. Maybe I did something to change the permissions manually, but I don't think so:

#2 Updated by bigfoot65 almost 9 years ago

Sounds like he download directory should be created on install. It seems too risky to depend on it being created when an app is downloaded.

There are apps with root privileges that use amahi-download versus wget. We would try to minimize them doing so as root, but the better solution in my opinion is creating it on install. That ensures it has the correct privileges. Depending on a trigger that may or may not occur is dangerous.

#3 Updated by cpg almost 9 years ago

  • Status changed from New to Assigned
  • Assignee set to cpg

This is debatable. My view is that the elevated privileges should be used as sparingly as possible, or, as we have seen, we will get more bug creep.

There should be no reason why a download (preferably amahi-download, not wget) cannot be done outside of an elevated script, then use it in the script, instead of doing it all inside.

The argument that the directory should be done at install time is also valid, but that may not help. The definition of a cache is to help things and part of the definition is that blowing the cache away (including the directory it holds the cache files), must not lead to errors. Hence I argue that creating the download cache directory dynamically is necessary, even if we create it at install time.

In other words, the contents of /tmp can be deleted at any time. Typically the temp cleanup crons do not delete something from there that has not been used within the last 30 days. If it were to be deleted, even if we created it at install time, the problem with permissions would still persist.

So, I think fixing the app scripts to not do downloads inside elevated scripts is really necessary.

#4 Updated by cpg almost 9 years ago

  • Status changed from Assigned to Closed

I think I reproduced this issue.

Here is the thing, apparently Ubuntu deletes some files and folders in /tmp/ upon reboot. This is not the usual unix behavior, but whatever, it's legit.

What i see is that lines 32 and 33 of the log are indicating the previous app install took place on July 22, and it was web-apps-proxy. This app has been found to have the issue of an amahi-download while on elevated privileges.

App: Amahi Web-Apps Proxy installed
=======  app install end        @  Thu Jul 12 20:43:29 -0400 2012 ==========

The previous app install was July 10th. This raises the possibility that /tmp was erased by a reboot some time in those two days.

I tried reproducing this (create a folder/files in /tmp, reboot, check and see) and it's consistent with my explanation above.

Since bigfoot65 has reviewed and fixed all apps known to have this issue, I think we're good.

Creating the directory upon install will not fix things in this case.


Also available in: Atom