Confusion with Symlinks

ℹ️ Support
1

Nextcloud version: 21.0.4
Operating system and version: Raspbian 10
Apache or nginx version: Apache/2.4.38 (Raspbian)
PHP version: PHP 7.3.31-1~deb10u1 (cli)

Hey all! I’m slightly confused with how my Nextcloud instance is reacting to symlinks.
I know that symlinks are not really supported, but I’m wondering if what I’m experiencing is expected.

I noticed the other day, that I was running out of space in my NC instance, and thought I’d move one of the larger project directories in my main project folder outside the NC premises while keeping a symlink to the project just for bookkeeping. I was expecting (maybe naively) that creating a symlink to a folder outside NC would clear the folder contents from NC, saving some space, while still allowing me to follow the symlink on the computer on which it was created.

This wasn’t the case though, and creating the symlink somehow made NC clear a portion of the data on the server side, while keeping some of it intact. According to NC, everything is now in sync.

This is what I’m seeing on the computer from which the symlink was created:

> ls -l
project -> [LOCATION OUTSIDE NC]/project/
> ls -l project/
add_checkpoint.sh*
audio/
code/
conda-environment.yml
doc/
fetch_models.sh*
fetch_mushra_results.sh*
memo.md
new-models/
plan/
presentations/
publication/
README.md
results/
spice/

And then on another computer that syncs to NC:

> ls -l
project
> ls -l project/
audio
plan
spice

Is this expected? What is happening here?

The output of the Nextcloud log in Admin > Logging is spammed with:

Error PHP Error: Cannot modify header information - headers already sent by (output started at /var/www/html/nextcloud/3rdparty/sabre/http/lib/Sapi.php:132) at /var/www/html/nextcloud/apps/dav/lib/Connector/Sabre/File.php#691

, but they are not related to any of the files in question (i.e. this is a symptom of something else I’m just now discovering).

My config.php file looks like this:

<?php
$CONFIG = array (
  'instanceid' => 'STUFF',
  'passwordsalt' => 'MORESTUFF',
  'secret' => 'MORE/STUFFS',
  'trusted_domains' => 
  array (
    0 => 'INTERNAL-IP',
    1 => 'EXTERNAL-IP',
  ),
  'datadirectory' => 'EXTERNAL/data',
  'dbtype' => 'mysql',
  'version' => '21.0.4.1',
  'overwrite.cli.url' => 'INTERNAL-IP/nextcloud',
  'installed' => true,
  'log_type' => 'file',
  'logfile' => '[datadirectory]/nextcloud.log',
  'log_rotate_size' => 104857600,
  'logtimezone' => 'MYLOCATION',
  'maintenance' => false,
  'dbname' => 'DBNAME',
  'dbhost' => 'DBHOST',
  'dbuser' => 'DBUSER',
  'dbpassword' => 'DBPASS,
  'trashbin_retention_obligation' => 'auto',
  'updater.secret' => 'MORESECRETS',
  'theme' => '',
  'loglevel' => 2,
);

My apache2 access log has lot’s of NC related PROPFIND and GET entries, but don’t know how much of it is relevant…

The errors in nextcloud.log are the same ones as in Admin > Logging.

Thanks a lot for any insights!

2

Hey!

I’m bumping this since it’s been a week without any follow-ups .

The symptoms remain the same. I’ve been updating the contents of the folder (in [LOCATION OUTSIDE NC]/project/), but this doesn’t cause any activities in NCs end, but rather it hangs in this weird in-between state with a subset of the original contents that I reported earlier.

As another trial, I tried renaming the symlink so that its name differs from the original, in hopes that this might trigger something in NCs end, but to no avail. Thus, the current situation is as follows:

Primary computer:

> ls -l
symlink -> [LOCATION OUTSIDE NC]/project/
> ls -l symlink/
add_checkpoint.sh*
audio/
code/
conda-environment.yml
doc/
fetch_models.sh*
fetch_mushra_results.sh*
memo.md
new-models/
plan/
presentations/
publication/
README.md
results/
spice/

NC:

> ls -l
project
> ls -l project/
audio
plan
spice

I would have expected that changing the name of the project to symlink would have triggered something, and I find it interesting that NC seems to ignore everything what is happening.

Does anyone have any insights?

3

Hey all,

I managed to resolve the issue!

The whole thing was about file locks in the NC database. It turned out my RasPi SD-card had started reaching its end of life, which finally manifested itself as the whole of my NC instance becoming unstable. This made me poke around the system a little more, which also made me realize that the SD-card wasn’t writable anymore. I’m assuming the NC MySQL database (which resides in the SD-card) had become out of sync with the actual files I had been storing (residing on an external HD), which then manifested first as file locks, and then eventually as the whole system crashing.

I made a backup of my local directory tree, exchanged the SD-card, rebuilt the NC files index (sudo -u www-data php occ files:scan --all), removed the file locks in the MySQL database (delete from oc_file_locks;, inside the MySQL prompt and within the correct database), and synchronized. After this diffing against my local backup of the directory tree shows nothing weird, and the original issue is also gone.

Win!