Windows Network Drive (WND)

To enable external storage, as the ownCloud administrator go to Settings  Admin  Storage and tick the checkbox Allow users to mount external storage.

The Config key to be entered as shown in the screen below, must be taken as described in Value to be entered in the mount point config key field.

Note that this authentication method can only be used by ordinary users if the admin hands over the Config key created. This is secure, as no password is exposed.

When the Kerberos Authentication has been set up, a necessary config key wnd.kerberos.servers needs to be provided upfront in config.php.

Enter the Kerberos Server ID to define the server and Kerberos credentials as shown in the image below.

Note that this authentication method can only be used by ordinary users if the admin hands over the Kerberos Server ID created. Consider this as a very sensitive information like a password.

When the data has been entered correctly, the moint point will show up as follows:

Starting with version 1.0.1 of the Windows Network Drives App, Access Control Lists (ACLs) are supported. To obtain the ACL information, two ACL providers can be selected:

On standard deployments, you don’t need to change anything. Just leave the field empty and the default nullPermissionManager permission manager will be used.

Regardless of which provider you choose, an ownCloud administrator should run a files:scan, manually, after changing the configuration, to update the permissions correctly. Otherwise, the permissions shown by ownCloud might be incorrect.

The SMB protocol supports registering for notifications of file changes on remote Windows SMB storage servers. Notifications are more efficient than polling for changes, as polling requires scanning the whole mounted SMB storage. While files changed through the ownCloud Web Interface or sync clients are automatically recognized by ownCloud, recognition is not possible when files are changed directly on remote SMB storage mounts. When using the listener, files changed on the SMB backend are recognized and a notification is stored in the database. The process-queue job reads these stored notifications and initiates further actions.

From version 2.0.0 the Windows Network Drive app includes an extension of the Activity app. This extension will allow the app to send events to the Activity app so the users know what happened in the Windows Network Drive storage.

Please see the following figure how a notification can look like. In this example, one user accessing the same host/share has changed a file. Other users will now get an activity notification about this change.

This extension requires the following components:

For setting up the wnd:listen and wnd:process-queue commands, see their respective sections above.

This extension is disabled by default. This means that no activity will reach the users. In order to enable this extension, you can edit the config/config.php file and add the following configuration:

The events that will be shown to the users are based on what the wnd:process-queue detects and changes in the ownCloud’s FS. Since the command includes some optimizations, some events might be inaccurate in some scenarios. For example, if multiple files are added in the same folder, there won’t be multiple "file added" events but only one "folder modified" in the parent folder.

The events are expected to reach only to the affected users. This filters out the users who cannot access the mount point, and also the users who do not have enough permissions in the Network Drive (Windows, Samba) to access that file.

As part of the Activity app configuration, users can decide which events they want to be notified about and how, in the activity stream or via email.

Users who can access the Windows Network Drive storage via share won’t receive activity notifications by default. You can add the following configuration in the config/config.php file to enable sending the activity notification to those users.

Collaborative WND (CWND) can only be set by an admin in Settings  Admin  Storage. This mount type cannot be selected by users in the user section. To prepare access for your mount point using the CWND mount type, you must provide a Service Account (SA) which is an ordinary SMB user granting read access to the share you want to mount. You can use one SA for all CWND mounts or separate ones. The SA is used to gather the contents of a share used by the WND Listener and provides a common file_id to all accessing users, while the accessing users can only access those files and folders for which they’ve been granted rights.

If you encounter issues using Windows network drive, then try the following troubleshooting steps:

First check the connection to the share by using smbclient on the command line of the ownCloud server. Here is an example:

Take the example of attempting to connect to the host MyHost, the share named MyData using occ wnd:listen replacing user and password accordingly. Running the following command would work:

To test if Kerberos has been setup properly for the use with WND, check the following on the server running ownCloud, replace keytab, SPN, <an-existing-domain-user> and <hostname_or_FQDN>/<share-name> accordingly. The domain user is the user on behalf the Kerberos ticket will be requested. Note that the shell user you are testing with must have access to the keytab file:

If your Linux distribution ships with libsmbclient 3.x, which is included in the Samba client, you may need to set up the HOME variable in Apache to prevent a segmentation fault. If you have libsmbclient 4.1.6 and higher, it doesn’t seem to be an issue, so you won’t have to change your HOME variable. To set up the HOME variable on Ubuntu, modify the /etc/apache2/envvars file:

In Red Hat/CentOS, modify the /etc/sysconfig/httpd file and add the following line to set the HOME variable in Apache:

By default, CentOS has activated SELinux, and the httpd process can not make outgoing network connections. This will cause problems with the curl, ldap and samba libraries. You’ll need to get around this to make this work. First, check the status:

Then enable support for network connections:

In openSUSE, modify the /usr/sbin/start_apache2 file:

Restart Apache, open your ownCloud Admin page and start creating SMB/CIFS mounts.

As said, the command processes all the stored notifications, squeezes them and scans the resulting folders. The process might crash if there are too many notifications, or if it has too many storages to update. The --chunk-size option will help by making the command process all the notifications in buckets of that size.

On the one hand the memory usage is reduced, on the other hand there is more network activity. We recommend using the option with a value high enough to process a large number of notifications, but not so large to crash the process. Between 200 and 500 should be fine, and we’ll likely process all the notifications in one go.

There are several ways to supply a password:

The WND in-memory notifier for password changes provides the ability to notify all affected WND storages to reset their passwords. This feature is intended to prevent a password lockout for the user in the backend. However, this functionality can consume a significant amount of memory. To disable it, add the following configuration to your config/config.php.:

Third party password managers or processes can be integrated. The only requirement is that they have to provide the password in plain text somehow. If not, additional operations might be required to get the password as plain text and inject it in the listener.

If both the argument and the option are passed, e.g.,

then the --password-file option will take precedence.

wnd:process-queue creates all the storages that need to be updated from scratch. To do so, we need to fetch all the users from all the backends (currently only the ones that have logged in at least once because the others won’t have the storages that will need updates).

To optimize this, wnd:process-queue make use of two switches: –serializer-type and –serializer-param. These serialize storages for later use, so that future executions don’t need to fetch the users, saving precious time — especially for large organizations.

While the specific behavior will depend on the serializer implementation, the overall behavior can be simplified as follows:

If the serializer’s data source (such as a file, a database table, or some Redis keys) has storage data, it uses that data to create the storages; otherwise, it creates the storages from scratch.

After the storages are created, notifications are processed for the storages. If the storages have been created from scratch, those storages are written in the data source so that they can be read on the next run.

The file serializer is a serializer implementation that can be used with the wnd:process-queue command. It requires an additional parameter where you can specify the location of the file containing the serialized storages.

There are several things you should know about this serializer:

Windows supports password lockout policies. If one is enabled on the server where an ownCloud share is located, and a user fails to enter their password correctly several times, they may be locked out and unable to access the share.

This is a known issue that prevents these two inter-operating correctly. Currently, the only viable solution is to ignore that feature and use the wnd:listen and wnd:process-queue, without the serializer options.

Setups with several servers might have some difficulties in some scenarios:

To set it up, make sure the listener is running as a system service:

Setup a Cron job or similar with something like the following two commands:

The first run will create the /opt/oc/store1 with the serialized storages, the rest of the executions will use that file. The second Cron job, the one removing the file, will force the wnd:process-queue to refresh the data.

It’s intended to be run in a different schedule, so there are several executions of the wnd:process-queue fetching the data from the file. Note that the file can be removed manually at any time if it’s needed (for example, in case the admin has reset some passwords or has been notified about password changes).

The WND app doesn’t know about the users or groups associated with ACLs. This means that an ACL containing "admin" might refer to a user called "admin" or a group called "admin". By default, the group membership component considers the ACLs to target groups, and as such, it will try to get the information for such a group. This works fine if the majority of the ACLs target groups. If the majority of the ACLs contain users, this might be problematic. The cost of getting information on a group is usually higher than getting information on a user. This option makes the group membership component assume the ACL contains a user and checks whether there is a user in ownCloud with such a name first. If the name doesn’t refer to a user, it will get the group information. Note that this will have performance implications if the group membership component can’t discard users in a large number of cases. It is recommended to enable this option only if there are a high number of ACLs targeting users. In order to enable this setting, you can edit the config/config.php file and add the following configuration: