knireis's picture

After installing the openphoto template in proxmox and pointing the brower to the openphoto ip, i get following:

You don't have permission to access /setup on this server.

Are there any steps to take to make it work?


Alex Bassett's picture

Same problem here with .iso and openvz , I can login to both via web min but i cannot access openphoto admin area gives : You don't have permission to access /setup on this server error .

I have also tried turnkey-init on openvz , still no access !

Liraz Siri's picture

Sorry, this might be a bug. I'll try to reproduce it and come up with a workaround.

Aris Moratalla's picture

Found a solution but I'm sure if this is the right one..

But it works.


logon to terminal on your server.

edit /etc/apache2/sites-available/openphoto file.

at the botto of the file you will find the code:

<Location /setup>
    deny from all
change deny to allow.

save changes.

hope this helps.
Jeremy Davis's picture

We'd really like to try to get to the bottom of this.

So was the domain or IP address that you used to use the appliance (ie in your web browser) the same as what you set in the firstboot scripts?

Jeremy Davis's picture

I just downloaded the OpenPhoto OVZ template (12.0-1) and launched in Proxmox. On browsing to (the container's IP; which incidentally I set as the domain during the firstboot/turnkey-init setup) it tells me that 'there's nothing to see here - log in to add content' (or words to that effect). I then logged in (via the link in the top right hand corner first, but tried again using the inline log-in link) using (which is the default admin email which I didn't change on turnkey-init) and the password that I had set (turnkey-init). It then successfully logs me in and suggests that I upload some photos.

Initially I did not auto install security updates on turnkley-init \but I ran that to check and it didn't seem to change anything. I also reran the OpenPhoto init script and set a real email address and it still works for me... So no idea what is going on for all you guys...

[edit] AFAIK (assuming it's like the other TKL appliances before) it shouldn't need to run 'setup' - it should already be done (and the TKL firstboot/init scripts take care of the details you'd normally run on 'setup').

@Aris - Once the Apache config is changed what happens then? Does it run some sort of setup/install type thing? (Like Jaisen suggest is the defualt OpenPhoto behaviour below). For security you'll want to (re)disable access to /setup once you're good to go, otherwise anyone can browse there and reset the settings and take control of your site (like Jaisen says below).

Jeremy Davis's picture

Always happy to hear from upstream devs! :)

I won't go into the in-and-outs of TKL appliances, but the basic idea is that they are fully pre-installed and configured ready to go. What little config info required is provided with an interactive firstboot setup console script. In the OpenPhoto appliance, these include OpenPhoto admin ('owner') email address, password and domain. As the name suggests, the firstboot scripts (aka turnkey-init scripts) run at firstboot after installation reboot (with the exception of some image types eg OVZ, OpenStack, etc - which either require values preseeded or manual initialisation by running 'turnkey-init'). So in the case of OpenPhoto, I would imagine that the appliance should not need to access /setup (as any required config has been done already from the console on firstboot). Ie the behaviour I experienced trying to reproduce this bug is what we would be hoping for.

Jeremy Davis's picture

So thanks again for your input Jaisen!

Resolving 'Issue #254' will eliminate the need to access /setup at all (in the context of TKL anyway) I would think. I would doubt that there would be any need to adjust DB/FS info in a dedicated appliance like TKL (although there may be edge cases, so great to have that info for reference).

Furthermore, the original post points to the configuration file not existing at `src/userdata/configs/{hostname}.ini`. The site redirects the user to /setup if it doesn't find that file. Is it possible that the cause is a hostname mismatch between what's int he browser and what TKL thought and used for the {hostname.ini} file?

Ahhh... I have a hunch that you have it in one! The info that you have provided and the fact that I used the IP address of my test appliance and didn't have the issue suggests that these others may not have done it that way thus causing this behaviour. I didn't write the firstboot/init script for the OpenPhoto appliance but I strongly suspect that the TKL script writes to that file, so if there is a mismatch between what the user inputs on firstboot and the hostname (/IP) used to access OpenPhoto it tries to run setup. Perhaps TKL needs to reword the firstboot script so this requirement is a little more explicit.

I'd be really interested to hear from the others who are experiencing this issue to confirm that this may be the issue/solution.

Jeremy Davis's picture

If you use an incorrect (or dummy) domain name or IP when configuring (eg leave the default then OpenPhoto will redirect to the /setup directory (which is disabled for security by default in the TKL appliance).

If you did that on firstboot and want to fix it the easy way, re run the firstboot script:

cd /usr/lib/inithooks/bin

Jeremy Davis's picture

Other than #4 your experience is nothing to do with the OpenPhoto appliance (and I can't comment on #4 but I assume that you are right).

You would/will have a similar experience with any of the TKL appliances when using OVZ templates (PVE or any other implementation of OVZ) - if you don't initialise the system when you create it. It is a shortcoming of the usuage of TKL as an OVZ template. But there is a solution - you just need to RTFM! :)

As documented quite extensively (on the OVZ template release announcement blog post, in the Wiki in relation to both OVZ templates and PVE usage and as comments on numerous threads), OpenVZ does not have a true console. Therefore, it is impossible to have interactive firstboot scripts run automatically (as they do in most other appliance builds). Or more correctly, it is possible, it's just not possible for you to interact with them (which causes services such as Webmin to hang and other anomolies).

Ideally, it would be nice if we had a way of preseeding the required values from the PVE UI (similar to what you do when launching via the Hub) so this isn't such an issue. But until that happens, running OVZ templates requires running of the whole firstboot sequence manually. To make this easier for users the devs have included a nice little generic wrapper script to do this (it's actually available in all appliances, not just OVZ ones).

Run it like this:


And it will run all the firstboot scripts (as happens automatically with an ISO install or a VM import). This will address your points as follows:

  1. Runs - allowing you to enter details from the start
  2. Runs - allowing you to enter a password for the MySQL root account.
  3. As you suspect this is a part of 1, but it also re-runs non-interactively (using openphoto as the user name) and sets a random string password for the account (which it also adds to the OpenPhoto config file so that OpenPhoto can interact with the DB).

Hope that clears it up for you.

knireis's picture

 i tried to re-run but after the above commands i get:

-bash: ./ no such file or directory

Jeremy Davis's picture

Sorry I left the 'bin' off. Fixing now... 

Jeremy Davis's picture

So no it hasn't and I doubt it will. It is a limitation of the OpenPhoto software itself. It can only be hosted on one domain name. So what you are trying to acheive is not possible OOTB. I can't speak for the OpenPhoto devs but i assume that it is to make the server more secure and reduce chances of things like cross-site scripting attacks. That's usually why it is done AFAIK. It is possible that there is a way you can hack it to make it host from multiple domains (or even be completely domain agnostic) but you'd need to contact the OpenPhoto community to see if that is possible and/or how you do it.

Having said that it is possible without hacking the software... But what you'll need to do is either 1) setup a reverse proxy (non-trival and probably not recommended unless you have other content you wish to serve). Or 2) set it up to serve on the external domain name (assuming you have a domain name linked to your external IP, either via some dynamic DNS provider or something else...) and reroute your internal network connection to the domain name.

If you want to go with 1) then I suggest that you check out google. I'm sure you'll find plenty of tutorials on how to do that.

If you want to go with 2) then rerun the config (as posted by me above) to resest your server to the external domain name you wish to use. You'll then need to add an entry to your hosts file (on every PC in your LAN that you wish to use the server from) that points to the local IP. The only issue with that is that if you do this with a portable device (laptop/tablet/phone/etc) you will only be able to view your photos within the LAN (it won't be able to find the IP when you are out and about).

Even without adding an entry to your hosts file you should still be able to connect to your server from within your LAN (using the external domain name) but that is dependant on your router/modem - it works with mine, but I have read others will not work). But be aware that if you do it this way then your connection is actually looping out to the internet and then back into your server. This will slow down the connection...

The other alternative (ie 2b) is to set up a local DNS server (on your home network). That is not too hard and is something I have done and am willing to share the info with you if you are interested. That will give you the best of both worlds (internal connection within your LAN and external everywhere else) without having to configure it on each machine.

Jeremy Davis's picture

To try to recreate your experience (with an aim to fixing it) can you please give me a couple more details please? Namely:

  • Were you using the latest version? (v13.0 currently)
  • What architecture are you using? (32 or 64 bit)
  • Where/how is the appliance installed? [Bare-Metal/Local Hyperviser (Proxmox, VMware vSphere or similar)/Local Desktop VM (VirtualBox, VMware Player, KVM or similar)/TKL Hub (or AWS)/another VPS/Cloud provider (please give details)]
  • If installed locally - what format/build type did you use/download? (e.g. ISO, OVF, VMDK file, OVZ, etc)

Thanks! :)

Jeremy Davis's picture

Sorry for all the questions, it just helps me try to recreate the issue you are having. I will launch from an ISO and see what happens. I'll post back when I have a chance.

Jeremy Davis's picture

It seems that the mirror you are using is private. It asked me for a username and password... So I downloaded from SourceForge instead (

I installed it to a KVM VM and all went smoothly. Once I had completed all the first boot scripts it was all working as I would expect (no additional install steps required...). So I'm not really sure what happened for you... Perhaps the version you downloaded was corrupt (or got corrupted on download)?

Also I noticed (as you mentioned) that the software appears to be called TroveBox, not OpenPhoto (as I was expecting too). It appears that OpenPhoto was rebranded as TroveBox. See here: (note that '' redirects to '').

Jeremy Davis's picture

Is that what you mean when you say "I edited the openphoto file as described earler in this thread"?

Bottom line is that I can't reproduce this issue. I just downloaded and installed a fresh version of this appliance. I ran the firstboot scripts (from the console), set up a domain (I just used the hosts file on my laptop) and it all just worked OOTB.

Can you walk me through the exact steps you took, one by one and maybe we can work out what is going on...

Jeremy Davis's picture

Sorry to hear of your issues, but if we can reproduce the issue then we can fix it one way or another (either make changes to the appliance or the docs...)

Add new comment