### Description
The Apache log file for my Owncloud site sporadically registers ”File does not exist: *[my OC root directory]*/data” errors from Owncloud; these go back to at least July last year (2014). To me this appears as if OC was erroneusly trying to access a hard-coded path for the data directory under the OC root, whereas my data directory actually resides elsewhere, entirely outside www my root, and there is no data directory under OC root.

The error timestamps indicate they only occur during daytime when I’m interacting with my installation (I’m the sole user), possibly only through the web interface, as I have the desktop client always on but the errors are rare relative to that. I use the web interface less and I think it corresponds to the timestamps better (but not all web interactions result in the error either, and I haven’t been able to pinpoint any specific action that triggers it).

Apart from those errors in the log my Owncloud installation appears work just fine, so the issue seems pretty harmless. I’ve considered creating an empty data directory under the OC root in case that might make the error go away, but then again it might just break something. Anyway, because it looks like a bug, I figured I’d better report it.

### Server configuration
**Operating system**: Debian Wheezy (I think; I’m a non-privileged user on shared hosting)

**Web server:** Apache/2.2

**Database:** MySQL 5.5.43

**PHP version:** 5.4.39-0+deb7u2

**ownCloud version:** 8.0.4.2

**Updated from an older ownCloud or fresh install:** updated

**List of activated apps:**
* Activity 1.2.0
* Deleted files 0.6.2
* External storage support 0.2.3
* First Run Wizard 1.1
* PDF Viewer 0.7
* Pictures 0.6.0
* Share Files 0.6.1
* Text Editor 0.4
* Updater 0.4
* Versions 1.0.5
* Video Viewer 0.1.3

**The content of config/config.php:**

”`
’datadirectory’ => ’/siilo/users/mummila/owncloud-data’,
’asset-pipeline.enabled’ => true,
’dbtableprefix’ => ’oc_’,
’dbtype’ => ’mysql’,
’forcessl’ => true,
’installed’ => true,
’logdateformat’ => ’l, j. F Y’,
’loglevel’ => 3,
’mail_smtpmode’ => ’smtp’,
’mail_smtpport’ => ’465’,
’mail_smtpsecure’ => ’ssl’,
’maintenance’ => false,
’max_filesize_animated_gifs_public_sharing’ => 5,
’preview_max_filesize_image’ => 5,
’session_lifetime’ => 60 * 60 * 24 * 15,
’theme’ => ”,
’version’ => ’8.0.4.2’,
”`

**Are you using external storage, if yes which one:** none

**Are you using encryption:** no

**Are you using an external user-backend, if yes which one:** none

### Client configuration
**Browser:** Chromium 37.0.2062.120 (build 281580)

**Operating system:** Ubuntu 12.04

### Logs
#### Web server error log
”`
[Sun Jun 14 13:57:52 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
[Sun Jun 14 13:58:47 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
[Sun Jun 14 14:29:18 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
”`

#### ownCloud log (data/owncloud.log)

(No recent events coinciding with the log above. Last entry below, with my desktop IP address redacted, from two days ago)
”`
{”reqId”:”71513d1b6f44276a8cd6cad21bc98864″,”remoteAddr”:”[my desktop IP]”,”app”:”PHP”,”message”:”Undefined index: extension at \/var\/www\/userhome\/mummila\/sites\/mummila.kapsi.fi\/www\/oc\/apps\/files_versions\/lib\/storage.php#320″,”level”:3,”time”:”2015-06-12T04:37:22+00:00″}
”`

The Unity Dash context menu for Rhythmbox currently has separate items for ”Play” and ”Pause”. I think Totem does better by eliminating those for a single ”Play/Pause” item which does both. I also think the interface should be consistent across these two applications. Rhythmbox-client even supports the same parameter as totem for this (–play-pause), so I created a patch for rhythmbox.desktop based on totem.desktop, which should accomplish what I’m after.

Using the KDE4 GUI (on a regular Ubuntu Unity desktop), the log prints (at least some) Scandinavian characters wrongly. I’ll attach a screenshot for demonstration. Meanwhile, the log viewer of the Gnome GUI displays the same characters without problems (I’ll attach a screenshot of that as well).

jani@saegusa:~$ apt-cache policy backintime-kde4
backintime-kde4:
Asennettu: 1.0.36~precise
Ehdokas: 1.0.36~precise
Versiotaulukko:
*** 1.0.36~precise 0
500 http://ppa.launchpad.net/bit-team/stable/ubuntu/ precise/main amd64 Packages
100 /var/lib/dpkg/status

jani@saegusa:~$ locale
LANG=fi_FI.UTF-8
LANGUAGE=fi:en
LC_CTYPE=fi_FI.UTF-8
LC_NUMERIC=”fi_FI.UTF-8″
LC_TIME=”fi_FI.UTF-8″
LC_COLLATE=fi_FI.UTF-8
LC_MONETARY=”fi_FI.UTF-8″
LC_MESSAGES=fi_FI.UTF-8
LC_PAPER=”fi_FI.UTF-8″
LC_NAME=”fi_FI.UTF-8″
LC_ADDRESS=”fi_FI.UTF-8″
LC_TELEPHONE=”fi_FI.UTF-8″
LC_MEASUREMENT=”fi_FI.UTF-8″
LC_IDENTIFICATION=”fi_FI.UTF-8″
LC_ALL=

I can, but it’ll be hard to get definitive evidence as the phenomenon can be quite elusive, and I cannot run the daily for very long periods (as it gets in the way of productivity). Obviously, if I catch it even once on the daily, it’ll be proof enough that the issue persists, but on the other hand, not seeing the issue may just mean it didn’t happen to occur during the time running from the daily.

(Upgrading the system to latest release would be a surer way to find out, but for now I intend to keep running 12.04 until the next LTS, 16.04.)

Hi Christopher, the apport-collected data above was gathered from my main desktop, which only has Intel graphics. (I mentioned the other system with Radeon just because it *didn’t* suffer from this problem despite having the same software. I no longer have access to that system so unfortunately I can’t provide the same logs from it for comparision.)

Note: I’m attaching a video below demonstrating the issue. In it I’m reproducing the problem with the amd64 ISO of 15.04.

Steps to reproduce:
1. Have a (virtual) machine with a clean 10 GB hard disk and 8 GB of RAM.
2. Start the installer, select ”Erase disk and install Ubuntu”, click ”Install now”.

What happens:
A ”Do you want to return to the partitioner?” window pops up, saying ”Some of the partitions you created are too small. Please make the following partitions at least this large:

/ 3.5 GB

If you do not go back to the partitioner and increase the size of these partitions, the installation may fail.”

Selecting Continue then goes on to an installation which fails due to lack of space as promised. This is because the installer has partitioned the disk with a 8+ GB swap partition, and only what remains of the 10 GB after that allocated to /.

What I expect to happen:
I know this is a tricky corner case, but I think there are better ways to deal with it than exhibited by the installer above. Here are some alternative suggestions I came up with:

1) change the way the disk space requirement is calculated for the ”Preparing to install” view: make it require at least the minimum ”/” size + expected swap size, thus notifying the user beforehand if the requirement is not met. (As you see in the video, currently it has the green checkmark even when the installer is about to fail predictably.)

2) have the installer select a partitioning scheme where ”/” is the minimum required and allocate whatever remains for swap; warn the user that swap will be too small to do hibernation.

3) at the very least, have the ”Do you want to return to the partitioner?” window describe the situation better. It was the biggest source of confusion for me because the wording implied I had partitioned the disk (which I hadn’t done) and prompting me to ”return to the partitioner” where I hadn’t been to.

The setup for unlocking an encrypted volume during boot using (only) a keyfile (on a detachable USB drive) usually calls for a keyscript to be specified as one of the encrypted volume’s options. But with systemd, such encrypted volumes can only be unlocked during boot by typing in a passphrase.

Steps to reproduce:
1. Have a LUKS encrypted volume.
2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
3. Boot.

What I expect to happen:
To have the volume unlocked by the script at boot time without manual intervention.

What happens instead:
Plymouth shows a prompt to enter a valid passphrase for the volume.

Workarounds:
Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven’t personally tried this.

* [1] https://news.ycombinator.com/item?id=8477913

@trentrichardson I’ve just tested the branch with the change and it’s working perfectly.

Hey @trentrichardson, and thanks for the response! The best I could figure in the meantime was to initialize the prompt differently in each branch, like so:

    if (user.isSignedIn) {
        states = {
            signOut: states.signOut,
            signIn: states.signIn,
            register: states.register
        };
    } else {
        states = {
            signIn: states.signIn,
            signOut: states.signOut,
            register: states.register
        };
    }
    thePrompt = $.prompt(states);

But it’s definitely better to have true support for this in the extension itself. Excellent!

Sorry if this is obvious, but how can I open a multiple-state prompt in a specific state other than the first one in the states object? In other words, in the first statesdemo example, how can I open the prompt in state1 instead of state0?

I’m working on a login/logout/registration form with each of the three as a separate state and would like to start the prompt in either the ”log in” or ”log out” state depending on whether the user is currently logged in or not.

(I’m trying to work out the solution reading Impromptu’s source code, but figured I’d also pose this question here for others like me to find in the future.)