SOLVED - Using owncloudcmd in bash scripts - one script works, the other does not. Both commands are nearly identical, and running from the same headless server

Desktop
1

NOTE: Edited to fix formatting errors

Expected behaviour

Directory synchronization should happen

Actual behaviour

URL is modified and a 404 error returned.

Steps to reproduce

  1. Using the owncloud command line client (this is in a bash script triggered by cron on a headless server)
    owncloudcmd -s --non-interactive --trust -u [username] -p [password] /var/opt/[name]/[other_name]/ https://[owncloud_server]/remote.php/dav/files/[username]/[other_name]/

The output of the command when run manually just as above, omitting the silent switch (-s), contains a 404 not found error. It is also NOT using the URL above:

23-09-25 19:54:04:275 [ warning sync.discovery ]: LSCOL job error “Error transferring https:/[OwnCloud Server]/remote.php/dav/files/[username]/[other_name]/remote.php/dav/files/[other_name]/[username]/ - server replied: Not Found” 404 QNetworkReply::ContentNotFoundError

Note that the URL in the command is “https://[owncloud_server]/remote.php/dav/files/[username]/[other_name]/”

While the URL in the error is
“https://[OwnCloud Server]/remote.php/dav/files/[username]/[other_name]>/remote.php/dav/files/[username]/”
(emphasis added)
I do have another script using this same command, except the username, password, and file/folder names are different. The command is identical to this one, and it works with no issue and does NOT change the URL I provided for the upload. I provided sanitized copies of both scripts, below (gist links)

Server configuration

OS: Both the OwnCloud server and the server running the script are Debian 11.7. The OwnCloud is bare metal, the script server is a VM.

Web server: Apache 2.4.56

Database: mySQL 15.1

PHP version: PHP 7.4.33

ownCloud version: 10.11.0

Storage backend (external storage): Local disk (/var/opt/owncloud/data)

Client configuration

Client version: owncloudcmd ownCloud 4.2.0.11670

Operating system: Debian 11.7

OS language: US English

Qt version used by client package (Linux only, see also Settings dialog): Qt 5.15.2

Client package (From ownCloud or distro) (Linux only): debian-5.10.0-21-amd64

Installation path of client: /usr/bin/owncloudcmd

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

Template for output < 10 lines

  1. Client logfile: Output of owncloud --logwindow or owncloud --logfile log.txt
    (On Windows using cmd.exe, you might need to first cd into the ownCloud directory)
    (See also Redirect Notice )

This failed because it tried to launch QT. The client is on a headless server with no GUI environment. I am unable to locate any ownCloud-specific log, and the URL above redirects to ownCloud Documentation Overview.

  1. Web server error log:
    [Mon Sep 25 00:00:01.582651 2023] [mpm_prefork:notice] [pid 3002956] AH00163: Apache/2.4.56 (Debian) OpenSSL/1.1.1n configured – resuming normal operations
    [Mon Sep 25 00:00:01.582680 2023] [core:notice] [pid 3002956] AH00094: Command line: ‘/usr/sbin/apache2’
    [Mon Sep 25 13:25:39.506229 2023] [php7:error] [pid 2297523] [client 212.1.211.240:45006] script ‘/var/www/owncloud/wp.php’ not found or unable to stat

Looks like someone was knocking at the door. Again. They came in on TCP/443 - so looking legitimate to the firewall. That is a majority of what appears in the error logs for Apache2.

  1. Server logfile: ownCloud log (data/owncloud.log):

This also failed because it tried to launch QT. This is a headless server, no GUI environment. When I went looking for a log file, the timestamp for /data/owncloud.log is Mar 5 2023.

Non-Working Script: (sanitized) Non-Working Sanitized Script · GitHub

Working Script: (sanitized)

Both scripts are run via cron on the same server. The purpose is to download shows for broadcast then place them in specific ownCloud locations for the automation system to convert and ingest automagically. The working script has to generate 2 versions of the URL as the producers of the show use uppercase letters sometimes and lowercase letters other times. They have never mixed cast. Therefore I generate two versions of the URL - one with uppercase and one with lowercase. If one fails, the other is tried. If that fails, the download failure is logged and the script terminates.

One other point to mention - both scripts were working until the SSL certificate for the server running ownCloud renewed, then only one continued to work. If you want additional information, please let me know what - and where to find it (thinking of the client and server logs I was unable to get because ownCloud tried to launch a graphical interface on a server that is headless and does not have anything installed to render graphics if I were to put a head on it).

Thanks in advance for any and all help. I tried to locate the original command line installation/usage instructions I used but am not able to find them. I am pretty sure they were on the ownCloud site, but no longer appear to be available - and the site layout looks different than what I remember from when I first set this up a few years ago. Note that the ownCloud server is used to receive files for ingestion into the automation system from others without issue. Some are using the web browser, some are using the desktop client (Windows and MAC, I believe).

2

This has been solved! I had posted in a small-ish private community I am a part of (not on any of the social media platforms because - ewww.) Someone there identified the issue - and I am not sure it would have been identified here. It was a case issue. The parts with the case issue were redacted in what I posted here, the sanitized version I posted there was not as sanitized as what I put here - since this is public and that is not :slight_smile:

The issue, specifically, was in the username in the server path. As an example, lets say the username was SomethingSSElse (not overly creative at 2345). In the path, I used SomethingSsElse. That was enough to cause the error. Why it appeared the way it did, however, threw me. Was not thinking about the username at all in the path - with the extra “/remopte.php/dav/files…” showing up.

Hopefully this will help someone else down the road.

Thanks!

1 Like
3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.