Symbolic link support

Hi guys,

I plan to move to nextcloud as soon as it comes out.
I was wondering if nextcloud has any plans for symbolic link support.
I currently backup and sync my project and work folders with owncloud, and there are some internal symlinks in there.
It would be nice if symlinks are also saved as is, meaning that they will appear as symlinks on other devices as well.
At the moment, I have to manually take care of these symlinks which is a bit annoying.
It would be nice if nextcloud has behaviors similar to Git with symlinks…

Cheers,
Kwang

4 Likes

AFAIK symbolic links used to work, but there were installations that had recursive links (think of it like people having symlinks inside their files which pionts back to a parent folder containing the link. This caused endless loops (and probably caused syncing to crash, maybe data loss) so it was dropped as a stability and security measure :slight_smile:

BTW, to add to your initial post: I don’t think ownCloud/Nextcloud is a good backup strategy. There are plenty others, less complicated solutions which are safer and faster. I see Nextcloud more as a platform for quickly sharing a file or collaborating :slight_smile:

2 Likes

I can’t agree more. Please don’t consider ownCloud/Nexcloud as a backup plateform, which it’s not. Nor it is a DMS, even with “version” app active.
It’s an excellent sharing platform, secured, multi-device synchronized, self-hosted. :heart_eyes:

2 Likes

Ditto. It’s really useful for that.

You do a lot of better if you do your backups using something like Bacula.

I see… it would be nice though if you can enable it manually.

Indeed :slight_smile: but I also need the cloud aspect of it, and I didn’t want to do things twice.

Hate to tell you but you need to do it twice because you need backups :wink:

Another thing that comes to my mind is users uploading symlinks to /etc/passwd :slight_smile:

1 Like

Yeap :slight_smile: I guess you are right on that one

Indeed, it’s a potential recipe disaster. Maybe it’s better off this way then

Just noticed that this and also the malicious links won’t really be a problem if symlinks are saved as is without any dereferencing in the client (which was my original suggestion). I also found this GIthub feature request.

1 Like

I understand why the symlinks have been disabled. And I’m rethinking the way I do and organise things. But I’m encoutering a problem. I can’t modify anymore the concerned folders through the web interface or through the sync client. I tried to suppress these symlinks directly on the server, but it seems that they still are in the mysql database, so client keeps restoring folders I try to delete.

Ok. First, supress the symlinks. Then sudo -u www-data php occ files:scan user_ID (for debian).

Hi folks, +1 from me on this one.

Symlinks may seem like a gimmick but for some of us they’re hugely useful. Can I make some implementation suggestions:

  • no dereferencing server-side, only client-side
  • symlinks have to point to other files inside your Nextcloud data dir (which to me means relative links only, and no use of ‘…’ to escape the data dir) - so the server would necessarily need to validate this when a new link is uploaded/modified on the server

I believe these will avoid most security issues, including the /etc/passwd suggestion above. The only vector this doesn’t handle is loops: If some malicious user creates an infinite loop of symlinks the apps reading this on the client’s operating system should handle this anyway, as these could be created on systems not running Nextcloud.

Other apps - notably git - are making use of these and now that NTFS’s support for symlinks is more public its usage will only increase under Windows. It’d be a great feature to have and might open up some new possibilities for how Nextcloud can be used. Building symlink support in will also allow Nextcloud to understand symlinks that come in from External storage providers.

J

3 Likes

I also agree - it wqould need to be supported securely, but this is an excellent feature.

1 Like

+1 to this.

I had proposed a subset functionality. It may not be useful for this backup situation, but it is related tot he main topic of symbolic links.

Hi, thanks for Nextcloud!

I would like to know if there is any news on the state of symlink support wrt the sync client.

Beforehand, I would like to clarify:

  1. In talking about symlinks, I am not interested in them in view of using nextcloud as a backup strategy.

  2. I am interested in storing symlinks “as they are”, with no dereferencing what so ever. With no dereferencing, symlinks cannot be a security risk.

  3. I know that not all platform support symlinks equally well. To me, it would be OK to have the sync client

    • Recognize the existence of a symlink on the client host and store it in the server as a file. For instance, if I have a symbolic link, such as foo.txt being a symbolic link to ../bar.txt, I would be happy of seeing on the server a foo.txt file with content symlink -> ../bar.txt. Then, the other way round, when getting something that is on the server, but not on the client, recognize if the item to be synced is a file whose content matches the symlink magic, and (i) if so; and (ii) if on a platform supporting symlinks, change the file on the client into a symbolic link.

Rationale

  1. To me symlinks support is critical to the storing and sharing of stuff in next cloud, because they are a part of how data is made accessible and searchable in large directory structures. Furthermore, when certain LaTeX documents are stored in a directory structure, they are functional to assure that LaTeX then finds things where it expects them to be, without having to duplicate files. When certain spreadsheets are stored in a directory structure, they assure that linked spreadsheets are found where they are expected to be without duplicating files on the client. When some code is stored in a directory structure, symlinks may be used to assure that the makefile finds things where they are expected to be.

  2. The behaviour described in point 3 above: is not disruptive; it can be made switchable on/off per client; does not require any support in the server (just in the sync client); can be acceptable for clients running on OSs that do not support symlinks; is compatible with webdav; lets the existence of symlinks be discovered and explored easily with the web interface since they are stored as regular files, but easily recognizable by their content for having a special function; by having no dereferencing neither in the server, nor in the sync software does not pose any security issue.

  3. The behaviour described in point 3 above is consistent with the symlink support provided in other pieces of software (e.g. git for windows, aka msysgit) on platforms that do not have good support for symlinks.

4 Likes

Posting to this thread to add my support for symlinks because they are immensely useful. Security considerations can be easily addressed so not a valid reason to avoid implementing this feature. Also, Dropbox supports symlinks.

3 Likes

@miguelg Are you sure dropbox supports symlinks?

Also, here is a link to a feature request that is related to symlinks

I’m definitely sure that Dropbox supports it, @kmcb. Here’s a screenshot that proves it:

2 Likes