• BCAM
  • New member
  • Offline
  • Registered: 03/06/2013
  • Posts: 4

Topic: Problems completing installation due to user/group/permission issues

I have unresolved ownership and permission issues with the installation of FrontAccounting.  My attempts have been as follows.

I have installed FrontAccounting (2.2.10-3) from the Ubuntu (12.04) repository .

I have also downloaded the current FA version (2.3.15) and extracted it into two different configurations in /var/www.

Each of the above processes has generated errors and failures before the completion of a fully functional FA.  I summarize the procedures and present state below

With guidance from this forum site, and others who have struggled publically and on line with this process, I have worked through "most" of the installation errors and ...

... I have a login screen for the native (2.2.10-3) installation (username/password fails, but I'm as far as that page),

... I have an installation screen for the most recent version (2.3.15) but have write permission errors for the configuration scripts and receive the following messages:

    the Database auth file     Required     ../config_db.php
         Can't write '../config_db.php' file. Check FA directory write permissions.
    Main config file     Required     ../config.php
         Can't write '../config.php' file. Check FA directory write permissions.
    Extensions system     Required
         ../installed_extensions.php
        ../company/0/*/installed_extensions.php
        ../modules
        ../modules/_cache
        ../themes
        ../sql
    OpenSSL PHP extension     '../installed_extensions.php' is not writeable
    Extensions configuration files and directories should be writeable.

I suspect I could cure the password problem on the repository installation with a purge, followed by a reinstall and a reinstall (from the repository and from within the program ... see, not as redundant as it appears) of the old version of FA.  I would prefer to activate the newer version as per a multitude of your comments.  But my efforts have presented a number of questions that orbit around directory and file ownerships and permissions.  Completion of the installation to begin work seems to hinge on these issues.

As I examine my existing copies in their native habitat, I find the following:

Scenario One (Ubuntu 12.05 repository copy of version 2.2.10-3):
Owner, Group and Permission settings resulting from a Synaptic Package Manager install:

    1.  For the main directory /usr/frontaccounting:
        drwxr-xr-x   21 root root  4096 Feb 24 16:44 frontaccounting  [755]
    frontaccounting's subdirectories are an owner/group/permission match except for:

    2.  company:
        lrwxrwxrwx 1 www-data www-data   24 Oct 30  2010 company -> /var/lib/frontaccounting [777]

    3.  lang:
        drwxr-xr-x 4 www-data www-data 4096 Feb 24 16:44 lang  [755]

    4.  and modules:
        drwxr-xr-x 2 www-data www-data 4096 Feb 24 16:44 modules  [755]

All of the remaining directories are drwxr-xr-x [755] and root root in permissions and ownership.

The php files are listed as -rw-r--r-- [644] unless they are configuration files and then they are rwxrwxrwx [777] (config_db.php -> /etc/frontaccounting/config_db.php; config.default.php -> /etc/frontaccounting/config.default.php; installed_extensions.php -> /etc/frontaccounting/installed_extensions.php).

The template file is rw-r--r--  [644].
End Scenario One.

Following instructions from the FA forum, the next two scenarios extract the frontaccounting archive directly without a package manager.  In Scenario Two , the extraction is placed into the Apache web root directory /var/www/frontaccounting.  In Scenario Three the extraction is placed in the directory /home/frontaccounting.

Scenario Two (2.3.15):
Using "gksudo engrampa" (I've discovered File Roller and other archive programs do the same) and telling the program to extract the archive into /var/www/frontaccounting, The shifts of ownership move from root:root to 1001:1001 as follows:

    1.  For the main directory /var/www/frontaccounting:
        drwxrwxr-x 23 1001 1001    4096 Feb 14 01:07 frontaccounting  [775]
    The ownership of frontaccounting's subdirectories are also 1001 1001, but the privileges change:

    2.  directories change from drwxr-xr-x to drwxrwxr-x:  [755 -> 775]
        lrwxrwxrwx 1 www-data www-data   24 Oct 30  2010 company -> /var/lib/frontaccounting  [777]

    3.  lang and modules change from drwxrwxr-x to drwxrwxrwx  [775 -> 777]

    4.  config.default.php
        -rw-r--r-- 1 1001 1001  10141 Feb 14 01:07 config.default.ph  [644]
        (not a link.  Following the analogy of the Ubuntu repository install, one would expect "-> /etc/frontaccounting/config.default.php"),

    5.  config_db.php -> /etc/frontaccounting/config_db.php does not exist
    6.  installed_extensions.php -> /etc/frontaccounting/installed_extensions.php) does not exist.

Scenario Three (2.3.15):
Working in the terminal, I created a frontaccounting directory in /home.  I extracted the archive to that directory and ended up with the following:

    1.  Ownership of the frontaccounting directory:
              drwxrwxr-x 23 1000 1000    4096 Feb 14 01:07 frontaccounting  [775]

    2.  All of the rest of the files match the ownership and permissions of Scenario Two, but with the 1000 owner and group.

From Firefox, I can access both the 2.2. and the 2.3 installation screens but cannot complete the installations.

I would like FA to reside either in the /var/www/frontaccounting directory, or in the directories the apt-get or Synaptic Package Manager repository installations would use, meaning the bulk of FA in the /usr/share/frontaccounting directory, and configuration files in /etc/frontaccounting (but this latter scenario might also diddle the installation database that is the back end of Synaptic and apt-get?).
However, where ever it resides, I want it to work in an user-independent manner.

"itronics" noted that /var is a directory not accessible via http, but with a simlink in /var/www it appears to be able to access the 2.3 installation in /var/www and also the 2.2 installation found in the /usr/share/frontaccounting directory.

I now have a 2.2 logon screen with a login page (true, it will not let me in at the moment because it says I do not have the correct user name and password).  I have an apache2 test page in /var/www that posts just fine.  I have a 2.3 installation screen with write problems.

Bottom line:
1.  Who should be owner of what?
2.  Who is the group for what?
4.  Who needs permissions for what and for how long?
3.  Can the 1001 owner be made a member of the www-data group and thus obviate the need to re-user and re-group the whole /var/www/frontaccounting directory system?  Assigning 1001 in that manner would still mean changing the group for the www-data files/directories but otherwise leaving everything alone.

Please advise.  And thank you in advance not only for whatever assistance you may provide but also for the marvelous work that's been done to develop this system.

2 Reply by apmuthu (edited by apmuthu 03/11/2013 05:09:45 am)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,160

Re: Problems completing installation due to user/group/permission issues

Make all files in /var/www/frontaccounting owned by www-data (user and group) 644.
Make all the folders in /var/www/frontaccounting owned by www-data (user and group) 755.
Install FA from browser.
Make the config.php owned and writeable by root user (644) only.
Remove the install folder.

Your version is too old and may have issues with Ubuntu's PHP 5.3.x

Use the latest v2.3.15 + fixes. Get it from SourceForge and the post release updates from the release forum post

apmuthu's Website

  • BCAM
  • New member
  • Offline
  • Registered: 03/06/2013
  • Posts: 4

Re: Problems completing installation due to user/group/permission issues

As per instructions above:
1.  Removed Scenario One installation with Synaptic PM:  (Ubuntu 12.04) FApackage 2.2.10-3
    That removed the /usr/share/frontaccounting directory and its contents.
    It did not remove the /etc/frontaccounting directory with the apache and php configuration files.
    Those files contained a path to /usr/share/f... and not /var/www/f....
    Not knowing whether this directory was installed by FA or by Apache or PHP:
        I edited the configuration files to reflect /var/www/f....
2.  Removed FA 2.3.13 from its Scenario Two and Scenario Three copies.

That rendered the system into an essentially "No Frontaccounting runnable presence" condition.
    Tested for FA access with browser.  Nada.
    Tested with full system search for files/directories (see /etc/frontaccounting/* above). almost nada.

3.  Downloaded 2.3.15 and extracted it (from within /var/www using tar -zxvf) into /var/www/frontaccounting.
    This created 1001:1001 group: ownership.

4.  Downloaded files from your second link provided (FA_v2.3.15_to_hg3198.zip).
    The link to sourceforge main download 2.3.15 is broken.  Apparently Sourceforge has restructured.
    Current link is https:/sourceforge.net/projects/frontaccounting/files/
    Unzipped the file and updated the directory.
5.  Changed owner and group from 1001:1001 to www-data:www-data: (sudo chown -hR www-data:www-data frontaccounting)
    Visually verified change through files and subdirectories from both terminal and GUI (see below).
6.  Changed permissions to 644 (sudo chmod -R 644 frontaccounting)
    Visually verified change through files and subdirectories from both terminal and GUI (see below).
7.  Restart apache2 server
8.  Testing.  This proved interesting.
    From the browser, testing apache server with localhost:
        It works!  This is the default web page for this server.
        The web server software is running but no content has been added, yet.
    From the browser with localhost/frontaccounting as the call:
        Forbidden
        You don't have permission to access /frontaccounting/ on this server.
        Apache/2.2.22 (Ubuntu) Server at localhost Port 80
    From a terminal: settings are drw-r--r-- 23 www-data www-data  4096 Mar  8 17:55 frontaccounting:
        $: cd frontaccounting
            bash: cd: frontaccounting: Permission denied
        $: sudo cd frontaccounting
            bash: cd: frontaccounting: Permission denied
    It requires sudo su for root access (#:) to the directory.
As a further test, I changed the ownership back to 1001:1001 and attempted to enter the directory with cd and sudo cd.  No go.  Now still requires sudo su.  I have changed ownership back to www-data:www-data

Please advise.  And thank you for your quick response to my last query.

  • Registered: 12/25/2007
  • Posts: 2,448

Re: Problems completing installation due to user/group/permission issues

You have so overcomplicated the installation process, that maybe instead of answering all your questions, I just describe how the latest FA version should be installed on any linux distro (forget FA 2.2. distributed with various linuxes, it is outdated and frankly I have no time for strugging with Debian maintainers to make the frontaccounting package at least installable):

. download latest FA version from sourceforge.net project page;
. unpack the tarball under any document root subfolder (on Ubuntu it can be e.g. /var/www/FA);
. direct your browser to http://localhost/FA/index.php
. read first installer page where all needed  diagnostics info is displayed;
. fix problems listed (if any);
. follow next installer pages until installation is finished;
. login to your new installation with user/pass provided during installation at http://localhost/FA/index.php
. if you still have any problems, ask on forum.

Keep in mind all the files installed need to be accessible by www server user as defined by your distro (it is 'www-data' under Ubuntu). It means you should install all the files with with www-data:www-data wonership, or fix it with chown command.

Janusz

  • BCAM
  • New member
  • Offline
  • Registered: 03/06/2013
  • Posts: 4

Re: Problems completing installation due to user/group/permission issues

Thank you.  I have an operational opening page. 
Please note:  apmuthu's permissions advised above (644) were incorrect and guaranteed failure.  644 (rw-r--r--) leaves no executability on any file (including the directory) by any user or group other than root (including Apache).  That did complicate the installation beyond measure.  Future readers should disregard that advice.
Might reconsider the "time" for Debian:  It and it's distribution stream are the fasting growing Linux market share on the planet by a significant margin.  Stability is a primary reason ... along with UNESCO.
I am not a Debian maintainer but might create a local deb for internal use to automate updating in the future.  If I find the time ... I'd be pleased to share the results if FA has any interest ... as I said ... if I find the time.  Thank you for giving me your time.
Installation problem solved smile

6 Reply by apmuthu (edited by apmuthu 03/11/2013 05:10:25 am)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,160

Re: Problems completing installation due to user/group/permission issues

The permission and ownership was stated to be for config.php file only and that too after the install was done - it gets created only during installation. This is mandatory to prevent getting hacked inadvertantly. The install folder should be zipped off and removed to prevent any over writes. The announcement link has been updated with changes till HG 3201.

In fact Debian is the platform of choice where a full OpenVZ VM build is available with PlaNetTel - no htaccess file complications and root-kit vulnerabilities on it's account. Full CUPS and multi font charting and SOAP API installed with FA pre-installed with DBs for 10 companies pre-created.

You're right that the folders should be 755 - stand corrected.

apmuthu's Website

  • BCAM
  • New member
  • Offline
  • Registered: 03/06/2013
  • Posts: 4

Re: Problems completing installation due to user/group/permission issues

Thank you so very much for your patience and your direction.  I have implemented your recommendations as you have stated them ... the course of wisdom over regret.  I have a fully completed and functional installation.  This topic should be considered resolved.   Setting up an additional company next.  Hmmmm ...