Too many levels of symbolic links

Support
#1

Hi
I just performed the (scheduled) revision 2 of a backup, and I got the following error:
WARN LIST_FAILURE Failed to list subdirectory: open /storage/Mona: too many levels of symbolic links
In the original backup I didn’t see any error since the log was truncated at 10000 lines, however the space occupied at the end of the backup is consistent
I did a find . -type l -ls in the directory, but no result was returned (which is consistent since I haven’t created any simlinks)

So what can be the origin of the failure? and is the backup successful or not? sice this is only a warning…
Here is the complete log:

----------------------------------------------------------------------------------------------------------------
Running backup command from /var/cache/duplicacy/repositories/localhost/1 to back up /storage/Mona
Options: [-log backup -storage backup_ds214 -threads 4 -stats]
2020-04-14 05:22:39.392 INFO REPOSITORY_SET Repository set to /storage/Mona
2020-04-14 05:22:39.399 INFO STORAGE_SET Storage set to b2://DS214-backup-MMY
2020-04-14 05:22:41.190 INFO BACKBLAZE_URL download URL is: https://f003.backblazeb2.com
2020-04-14 05:23:49.214 INFO BACKUP_START Last backup at revision 1 found
2020-04-14 05:23:49.215 INFO BACKUP_INDEXING Indexing /storage/Mona
2020-04-14 05:23:49.215 INFO SNAPSHOT_FILTER Parsing filter file /var/cache/duplicacy/repositories/localhost/1/.duplicacy/filters
2020-04-14 05:23:49.215 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2020-04-14 05:23:50.512 WARN LIST_FAILURE Failed to list subdirectory: open /storage/Mona: too many levels of symbolic links
2020-04-14 05:23:59.939 WARN SKIP_DIRECTORY Subdirectory  cannot be listed
2020-04-14 05:24:00.179 INFO BACKUP_END Backup for /storage/Mona at revision 2 completed
2020-04-14 05:24:00.180 INFO BACKUP_STATS Files: 0 total, 0 bytes; 0 new, 0 bytes
2020-04-14 05:24:00.180 INFO BACKUP_STATS File chunks: 0 total, 0 bytes; 0 new, 0 bytes, 0 bytes uploaded
2020-04-14 05:24:00.180 INFO BACKUP_STATS Metadata chunks: 3 total, 8 bytes; 3 new, 8 bytes, 35 bytes uploaded
2020-04-14 05:24:00.180 INFO BACKUP_STATS All chunks: 3 total, 8 bytes; 3 new, 8 bytes, 35 bytes uploaded
2020-04-14 05:24:00.181 INFO BACKUP_STATS Total running time: 00:01:19
2020-04-14 05:24:00.181 WARN BACKUP_SKIPPED 1 directory was not included due to access error

Thanks for your help!

adit: additional info: the original backup seems ok since I can see all the files (in the restore menu) however, the revision 2 is empty…

#2

For some reason Duplicacy thinks /storage/Mona is a circular symlink. Duplicacy always use the same code to list the directory, whether it is the initial backup or not, so I think it is more likely that something changed to that directory between the two backups.

#3

Hi
thanks for your answer
it’s weird because the directory is mounted (it is a NAS shared directory) the same way as another for which the backup is working fine
I actually use duplicacy in a docker container and the volume is mounted in a docker compose this way

volumes:
      - ./duplicacy/config:/etc/duplicacy
      - ./duplicacy/cache:/var/cache/duplicacy
      - /DiskStation:/storage

and in the /DiskStation are both directories, one working not the other
if I open a shell in the docker container and if I do ls -la /storage/
it gives this:
dr-xr-xr-x 2 root root 0 Apr 6 13:29 Mona
but ls -la /storage/Mona/
gives this: ls: /storage/Mona/: Symbolic link loop
this is weird

#4

OK, I changed the owner of the directory on the host and it solved it…
I don’t understand why it was an issue since everything was accessible, and the error is not very explicit but it works now :smiley: