FAQs

The Sciebo ID consists of a local identifier, the @ symbol, and your institution’s scope. Therefore, the Sciebo ID looks like an email address. In many cases, the Sciebo ID and email address are even identical. However, these Sciebo IDs and email addresses are processed differently. At some institutions, the Sciebo ID does not allow any conclusions to be drawn about your actual university user ID. These institutions anonymize your central university ID.
You can view your Sciebo ID here in the Login field.

We cannot guarantee that the local ID assigned to us by your university is unique across all instances. However, for some functions, it is essential that each Sciebo ID is assigned only once. This also allows us to see, based on the Sciebo ID (except for guests), which university users are registered at. This uniqueness is also helpful when sharing data.

There are several, mostly technical, reasons for this. The Sciebo web server only has read access to the central user database. And the developers, both ownCloud (back then) and Nextcloud (now), don’t offer a suitable account management system. So, colleagues developed the account management system mySciebo their own. Unfortunately, it can’t be directly integrated into the system. However, we’re trying to make account management more visible and have already integrated it into the regular user menu under the mysciebo item.

Account management is not implemented in the standard Sciebo web interface. Everything related to account and project box management, etc., can be handled in the mySciebo portal. Switch to www.sciebo.de or hochschulcloud.nrw in your browser and then click on My.Sciebo in the top bar. On the page that appears, select your higher education institution and confirm your choice with Select. In the subsequent mask, enter your central university ID along with the associated password. Your entitlements will be checked in the background. If everything is in order, you can extend your account using the account functions.

If you are still entitled to use Sciebo, you can extend your account as described above. In the process, it will be reactivated.

If your account name has changed (for example, because you have switched to another university and received a new ID), you must re-register. Unfortunately, you can no longer use your old account. You can manually transfer your data from the old to the new account if needed.
Since migrating to Nextcloud, this can be easily achieved by transferring folders and files to the new account via the web interface. Information on this can be found here: Transfer of ownership

As long as your ID has not changed, you only need to extend your sciebo-account in mySciebo to update your data.

As long as your ID has not changed, you only need to extend your sciebo-account in mySciebo to update your data.

We take your email address from the data transmitted to us by the DFN (German Research Network). To change the address, it must therefore be changed centrally at your institution. Then you simply need to renew your sciebo account in mySciebo to update your data.

Please contact your local support. The colleagues there can set up a moratorium for you as admins in the mySciebo portal. Any project boxes you manage should be transferred to a substitute person. You can do this yourself in the mySciebo portal for the project boxes you manage.

If you leave your institution, you can no longer extend your sciebo account and it will be blocked after a grace period (max. 1 year from the last extension) and then deleted. If you forgot to secure your data before it was blocked, open a support ticket.
Your identity will then need to be verified (e.g., via video identification), as we take data confidentiality very seriously. For the video identification process, you will need a high-resolution webcam and a valid identification document. Additionally, a valid email address must be provided, through which you will receive the temporary access information. Please back up your data immediately, as we are not permitted to repeat this activation process indefinitely.

Unfortunately, students cannot currently increase their storage volume.

You can request a project box.

Please contact your sponsor; they can reset your password or extend the validity of your account in the guest management of mySciebo.

Once a year, you must confirm with the extension of your account that you are still authorized to use Sciebo. The funding conditions of the state of NRW require us to that only students and employees of the participating universities use Sciebo. Since we do not have a mechanism that actively notifies us of the expiration of authorization, this is unfortunately the only way. This restriction, however, also has an advantage. If we had such an automated data transfer from the institutions, we would have to completely delete the accounts immediately after the authorization expires. However, we can currently grant a grace period of one year.

There are several errors that can occur. We can only address the most common ones here.

• Login fails after selecting my institution:
  The common mistake here is using the Sciebo login credentials. You need to use your central university ID with the corresponding password.
• Login worked, but I’m told I’m not authorized:
  This could be because your user authorization has actually expired. Either open a support ticket or contact your university’s local support team to clarify the situation.
• Login worked, but some data seems to be missing:
  Occasionally, for whatever reason, we don’t receive the complete data set from your home institution. In this case, please contact your local support team for clarification.

Important:
Guests do not have access to the mySciebo portal, as authentication via the DFN is not possible.

Sometimes this is a temporary error. At this point, we receive the data from your home institution. If it is not clear from this data that you are authorized to use Sciebo, we have to reject the account renewal. You should receive an overview showing what was transmitted to us. This error can occur temporarily because several services (DFN, your institution’s IDM, and our system) communicate with each other. Therefore, please try again after about an hour. If the error still occurs, please contact your local support hotline directly, as we in the Sciebo team do not have access to this data. We only evaluate what we receive.

No, the mentioned protocols are not supported. You can use sciebo via the web interface, the desktop client, or the apps.

Basically, it is possible to use sciebo via WebDAV.
We explicitly advise against using it as a network drive or embedding it using webdavfs, as this often results in data loss. Other WebDAV clients may work, but we do not offer support for this. Use sciebo best via the web interface, the desktop client or the apps.

rclone works well on various platforms. Please note that rclone is not as clever as the sciebo client, and the data synchronization creates relatively high load on our systems. For larger data volumes, we ask you to choose the synchronization intervals as large as possible or to synchronize only partial quantities very explicitly.

There can be various reasons why data is no longer found.
First, check the following solutions:

• If you have accidentally deleted data, you can restore it within 7 days (depending on available storage space, also significantly longer) if you are the owner of the data. Log in to the web interface for this and select the trash can from the left menu. The data listed there can be restored directly.
• If data is missing that has been shared with you, contact the person who shared the data. They may be able to restore the share or the data (if they were accidentally deleted). Also note that data shared by a user is no longer available if their sciebo account is deleted.

If your data could not be restored in this way, open a support ticket. Also, remember to make regular backups of your data.

No, because the amount of data is very large (it’s several thousand terabytes, more than a billion files), we cannot perform a complete backup. However, the storage system is designed to be redundant and fault-tolerant, so the data is as secure as reasonably possible. We do, however, create a snapshot once a day, which we keep for several weeks. We can access it for extremely important data. This represents a considerable effort for us, though. Therefore, we cannot promise every user that we will be able to restore data from it.
Please create your own external backups regularly!
If we are to search for and restore lost data, we need exact information about the storage location and the date/time of the data loss. If recovery is possible, we will then take the data from a snapshot taken immediately before the data deletion. Because this process is very complex, we cannot accommodate very specific requests or individual file lists.

If the person with whom you want to share data is a member of a university participating in the Sciebo project, they can create a Sciebo account. About a day after registration and account activation, you should be able to find them via the address book search. Alternatively, you can also add them using their Federated Cloud ID.
If this option is not available, you can share the data via a public link. Please remember that anyone with this link will be able to access the data. Therefore, please be sure to protect this link with a password. Staff members of participating universities can also invite external guests.

If data needs to be shared with users outside your organization and you don’t want to share it via a public share link, the system uses the Federated Cloud ID. This consists of the user ID, an @ symbol, and the target server. For external Sciebo users, this means a relatively long ID with a total of two @ symbols. If you are asked for your Federated Cloud ID, please check the web interface under Settings/Sharing. The information is displayed in the upper section. The Federated Cloud ID can also be easily copied to the clipboard with a single click.

We are now aware of this error on Windows clients and have reported it to the manufacturer. Hopefully, a permanent solution for this error will be found soon. Many, but not all, users are affected; thankfully.
Until a permanent fix is ​​available, you can try the following workarounds:
a) Install the old client version, which you can find at https://install.sciebo.de/Sciebo-Windows-3.17.3-34773-x64.msi. Afterwards, please disable automatic updates in the General settings, as otherwise the system might try to install the faulty version again.
b) Remove the local account from the client and recreate it. Please do this with utmost care and caution, and only if you have created a backup of your local data. If you set up your client account with the VFS option, no local data should be present. This action isn’t quite so critical.
c) If you log in to your Sciebo instance via the standard browser before updating the client, the problem does not occur, according to the manufacturer Nextcloud.

We apologize for the inconvenience. We are testing the new clients to the best of our ability before activating the automatic updates that the vendor, Nextcloud, will then distribute for us. Since it doesn’t affect all users, we don’t want to disable the update function centrally.

Notice: The next Sciebo version, which we are currently testing, is intended to resolve the problem.

If no selection is offered despite an existing server connection, it is usually due to the fact that you are working with VFS (Virtual File System). Initially, only the metadata is synchronized with your system, not the file contents. Since hardly any space is consumed on the hard drive, a selection of the data to be synchronized is not necessary.

First, check if the folder to be synchronized is larger than the set limit (default 500 MB). You can find this in the client settings. If the folder is larger, you can either deactivate this limit (if there is enough disk space) or specifically release it in the folder selection. Sometimes the folder does not appear in the list at all, but other folders do. This is often due to some restrictions of the Windows file system. The folder usually contains data that Windows cannot handle. This includes files and folders that contain an invalid character. Colons mark device names and should not be used in the Windows context. Problematic are also spaces at the end of directory names.

VFS stands for Virtual File System and is a feature that is used in particular under Windows. It can be useful to switch to VFS, especially on systems with little free hard disk space. Initially, only the metadata (i.e. the file names, timestamps, etc.) are downloaded from the server. The file itself only lies on the server and the content is only downloaded when you need it. This makes the synchronization faster and consumes less disk space and also less bandwidth. You do not (and cannot) have to decide what is synchronized. That’s it with the advantages. The desktop client is also recommended by us so that you have a kind of “backup” of your data, should you ever have no access to the server. If you work with VFS, this does not work, since only the metadata, not the contents, are stored locally. We also strongly recommend having at least one external backup of your important data. This is quite difficult to do. According to our knowledge, external backup tools are necessary for this if you do not want to download the entire content of the cloud with every backup. With a few GB, this is usually not a problem, but with larger employee accounts, this is no longer practical. We have also observed that synchronization is extremely slow with accounts that have a large number of objects (files & folders). A precise cause could not be determined so far. Perhaps the implementation in the operating system is not yet optimal.

1. Log in via the browser.
2. Go to Personal Settings → Security.
3. Remove the iOS device from the list.
4. Write an app name (e.g. iPhone) in the field at the bottom of the page and click on Create new app password.
5. Then use the QR code to connect the app to the server.

This unfortunately happens in rare cases. We have not yet found a way to reproduce the problem. Therefore, we do not know the cause of this behaviour and can only help to a limited extent.

• Check in the task manager if there is definitely no client process present. The software may be running in the background.
• Please check the system logs of the computer to see if there are any indications on problems.
• Check on our download page if you have installed the current version of the client.
• Deactivate software such as virus scanners or VPN for testing purposes.
• Please reinstall the client completely.

The URL to enter is the same as for the web interface. You can find the list here.

We understand users’ desire to avoid installing too many different programs on their computers. Currently, it is still possible to access Sciebo with the ownCloud client software. However, we cannot guarantee this in the long term, as the two products, ownCloud and Nextcloud, are being developed independently. It is possible that the ownCloud client may stop working altogether or that data loss may occur. Therefore, please be very careful when proceeding in this way. We cannot and will not provide any support whatsoever for client software that is not from Nextcloud or officially supported!
If the ownCloud client should ever stop working reliably, a switch to the Nextcloud version of the software will be necessary. Unfortunately, you cannot simply transfer your configuration and data. This means you will have to install and configure the new client. After the first complete and successful synchronization, you will likely need to copy more recent data from the old ownCloud Sciebo directory to the data directory of the new client. Command-line tools like ROBOCOPY (Windows) and rsync (Linux, possibly macOS) are available for this purpose. These tools are not straightforward to use. A detailed guide would be beyond the scope of this document. We may provide a short guide later.
The required server list for original clients from the manufacturer can be found here.

Please contact support so that the problem can be resolved. Usually, a file scan needs to be performed for the affected account. This means that if the data is located in a shared folder, this action must be performed for the account of the person sharing it. To explain: Checksums (so-called eTags) are stored in a database. If this checksum doesn’t match the calculated checksum of a file, this message appears, and the client refuses synchronization. This error can occur if files are written very frequently in an extremely short period of time. Presumably, several processes are running in the background to calculate the checksum, and a process based on outdated data finishes last and then writes this value to the database.

The web interface lies a bit: no email is sent. It can only be shared with IDs that have logged into sciebo-Overleaf once and created a project. Then you can share with these people via the Sciebo ID. It is not necessary to use the federated Cloud-ID (with the double @), but you must use the normal ID that the people have at their respective instance.

We use the open source version of Overleaf, as found on GitHub. This means that we have no influence on the features that can be used. The integrations of Zotero or Github cannot be installed for this reason.

Unfortunately not.
The Overleaf installation in sciebo is (currently) not fully integrated into sciebo and therefore data cannot be imported or exported directly into sciebo. Overleaf projects can only be imported and exported indirectly as a .zip file.

The current server list can be found here.

This is currently not possible.

Since the migration to Nextcloud these groups are now under Contacts/Teams.

Probably something went wrong during the transition of the instance from ownCloud to Nextcloud. The error is known to us. Unfortunately, we do not have a central repair tool and we do not want to deactivate the 2nd factor for all users for security reasons. Please write a support ticket with your university email address so that we can reset the 2nd factor.

There are several possible causes. Here are the most common:

1. The password is incorrect.
2. The Sciebo ID is not case-sensitive. Unlike ownCloud, Nextcloud is very particular about this.
3. The central university ID was used instead of the Sciebo ID.
4. The account does not exist.

This is for data protection reasons. Someone trying to hack an account should not be able to tell whether a Sciebo ID exists. We ask for your understanding for this measure. If you are unsure whether your account has been deleted in the meantime, please check the mySciebo portal.

The most common mistake is trying to log in to your sponsor’s server. Guests can only log in to the guest instance.

We developed our own guest concept before ownCloud or Nextcloud integrated this feature. The advantage is that these guests truly function system-wide and are not limited to the respective instance. This allows for much more flexible collaborations, even across multiple universities. Therefore, we have a separate guest instance.

• Due to the funding requirements of the state of North Rhine-Westphalia, guests are not allowed to have their own storage quota.
• Since guests do not have their own quota, they can only store or modify data in shares where they have the necessary permissions.
• Guests are not allowed to share further.
• Guests cannot use the mySciebo portal to renew their account or reset their password. Should this be necessary, please contact your sponsor. You will then receive an email with the appropriate instructions.

We currently do not have a function to provide this information. Therefore, please be sure to keep the emails you received when registering your guest account. If the emails have been lost, please send us a support request. We can investigate this for you.

Unfortunately, we can’t do much about this, as we have to delete a considerable amount of data for data protection reasons. Therefore, it’s generally advisable to maintain contact during collaborations and also obtain the names of any representatives. In this case, our hands are usually tied in support.

Please contact your sponsor first to have the account reactivated or a new one created. If that does not work, please try another academic staff member of the project so that the sponsorship can be taken over by a substitute. We are not allowed to extend guest accounts or transfer the sponsorship.

The new apps (Decks, Surveys, Tasks, Forms) and the calendar are currently not capable of this. For the Decks app, the manufacturer has announced the Federated function, which is expected to come with server version V33. As of now (Q1/2026), we are currently transitioning to V31. The other apps are also expected to be enabled for this, but we have neither confirmation nor a scheduled date.

There are a few things to consider when it comes to apps. Therefore, we take a very conservative approach to activating additional apps. We appreciate your understanding.

• An additional app should not affect the stability of the overall system.
• The app must not rely on other/external services, as your data must not be shared.
• The app must be supported by the developer.
• The app must be updated regularly.
• The app must not incur any additional licensing costs.

The problem is, once an app has been activated and is in use, it’s difficult to deactivate it again for any reason. The example of Overleaf showed us this some time ago. That’s why we’re being cautious now.

This is not currently possible. Saving as a PDF via the operating system’s print function does not work reliably because only the first page is displayed. Therefore, this is not a bug in the app. We also do not have official support for this app, so we cannot make any demands. Nextcloud recommends using Collabora for these purposes.

If you only occasionally want to receive very large files, using a public link share is a good option. To do this, create a folder where you want to receive the file and click on the share icon and select “Public Links”. There you can create a link, and for single use you should set an expiration date and password, as well as, of course, the option to upload files. See also instructions to file drop.

Unfortunately, this function is not currently available. However, you can configure individual information in your profile settings. A complete opt-out option is not currently offered by the vendor.

There are some good reasons to create external backups. Basically, the data in the cloud is well protected. But technical circumstances can lead to data loss occurs, for example when using WebDAV or VFS. Our system uses various protection mechanisms to prevent data loss. The data storage is distributed redundantly across two locations. The failure of individual hard drives can also be compensated for by the system. However, user errors can cause data to disappear. Problematic here is in particular the use of shares. If you store your data in the account of the owner of the share, then if this account is deleted by the system, for example after the expiry of the authorization, then this also applies to the data. We are forced to do this for data protection reasons, on the other hand, due to the limited storage capacity. Our system also sends corresponding warning emails to the recipients of shares before the accounts are deleted. But unfortunately, these messages are often ignored. If a third person has access to the same share, they are probably authorized to delete the data or move it to another location outside the share. This is the current standard setting when creating shares. We do not create backups due to the huge amount of data. The storage system only creates so-called snapshots once a night. But we have to delete these or thin them out after a few weeks due to space reasons. In addition, searching in the snapshots and restoring from them is not quite easy and very time-consuming.

Collabora and OnlyOffice are open source and hosted by us. This operating mode is not possible with Microsoft Office. Therefore, for data protection and security reasons, Microsoft Office 365 is not a viable option. In addition, Microsoft Office works less reliably on the scale of sciebo.
Since the upgrade to Nextcloud Version 30, the default document editor has been set to Collabora (aka Nextcloud-Office). This has technical reasons that the manufacturer Nextcloud prescribes for us. Currently, there may still be problems, especially with the formatting and character sets of MS documents in Collabora. In this case, you can open your MS documents via the 3-dot menu with OnlyOffice until further notice. We hope that the support for these documents in Collabora will improve in the medium term.

We are nerds and therefore, by definition, blind to our own operations. We have partially become accustomed to the processes and quirks of the system. However, we know that neither the manufacturer nor we always offer the optimal solution or the perfect workflow, as it is now so beautifully called. Therefore, we are grateful for suggestions for improvement. And now comes the big but: We use software from the manufacturer Nextcloud (previously ownCloud). It is a standard product that we have visually adapted to the Sciebo brand. Changes in the server service would therefore generally affect all other external users as well. Therefore, the chance of achieving something must be realistically assessed. A single voice unfortunately often goes unnoticed. But if you can already win many supporters for your idea in advance, this increases the prospect of success. If we like a request for change and it seems plausible, we will gladly pass it on to the manufacturer Nextcloud.
Anyone who is themselves a web developer might consider joining the Community and taking direct influence on the development of the product there. In that area, we are unfortunately tied by personal reasons (human resources).

We typically respond to tickets within one business day.

We are not a commercial service and therefore are not available 24/7. We work on regular weekdays, i.e., Monday to Friday, excluding holidays, etc. We don’t have fixed office hours, but we are generally available from 9:00 a.m. at the latest, and someone should be available until 4:00 or 5:00 p.m. On Fridays, we sometimes take an early weekend.

For urgent problems, the respective universities have telephone hotlines for first-level support. The second-level support team, on the other hand, is only available by phone in exceptional circumstances. This is because we are only four colleagues in this team, responsible for virtually the entire operation of Sciebo, including hardware, further development, etc., for approximately 200,000 users. We ask for your understanding that we therefore need to isolate ourselves somewhat.

We are engineers. Therefore, it can sometimes happen that we also respond at that level. We do our best to prevent this from happening. Please explain exactly where the problem lies. We will then try to explain the matter in a less nerdy way.

You are welcome to submit this question to us via the contact form. However, we don’t know everything either. You might find the answer you’re looking for in the documentation from the manufacturer, Nextcloud.

We are human and we make mistakes. Whether it’s in spelling, wording, or even the fact that some texts have been copied from the old help pages for ownCloud-Sciebo. We are happy to be corrected and can amend these pages promptly so that the corrections benefit all users. Simply send us a support ticket.