 My name is Michael Roth from the University of Augsburg. I want to talk to you about our attempts to connect our NFS knowledge with cover of authentication to NextCloud. I want to start by telling you what we have. We have our campus file system. This is a central NAS file service for all users. Accessing the CFS is possible for Windows clients via SNB and Linux clients via NFS. To control the access, we are using NFS ACS, which are translated for SNB users into NTFS ACS. By this, we are applying the ACS to all connection types. What do we want? We want to access the NFS from off-campus, mainly for tablets, phones, or laptops. For security reasons, we don't want to store passwords at the NextCloud server or even give the server root access to our complete campus file system. Therefore, we want to mount our CFS as external storage. And because we live in a Linux world, which means we run Linux on our file service exporters, we run Linux on the NextCloud server. And we're also using NFS for here. ACS, we want to connect NextCloud with NFS to our file service. Way to get there, I created a user-carverous app, which intercepts the username and password and tries to get a carverous ticket for the user. Important there is the part with the pseudo, which meant the carverous ticket is stored in the user context. At the next step, I did a bind mount to remount our complete campus file system at another location, but also issued this command in behalf of the user. By doing so, all access to the new mount points, mount username, will be masqueraded to the campus file system becoming from the logged in user because the carverous ticket is present. I then extended the files external app for a new storage type called a CFS and to do some stuff like ignoring SimLinks because SimLinks can cause some problems, mainly infinite loops, or also provide some ways to access the storage of other users. I registered the stream wrapper for the prefix CFS, which could handle the access to the CFS and could ignore SimLinks. By doing this, we were able to grant users access to our campus file system via NFS and carverous authentication. We run into some problems, mainly changes made via NFS or SMB on the campus file system are not reliably picked up by Nextcloud. And the other problem that the scanner restarts on failure, which was inconvenience because it starts at alphabetically and there are always the dot cache folder. But in the dot cache folder, there are always files which are constantly changed. Therefore, the scanner didn't go through to the end and stops by dot cache. And this was with an old version of own cloud by migrating to Nextcloud. This issue seemed to be solved. Also a problem because we don't store passwords on our Nextcloud server, we won't be able to share the conventional way from Nextcloud. Therefore, we want to implement sharing with ACLs, which may mean if I share a file with someone, the ACLs on the file system are adapted or changed so that the new user has direct access to this file. By doing so, we're allowing access to all three ways which meant the new user can access the shared file via NFS, SMB or via Nextcloud. Some problems must be considered for reasons, for example, is resharing allowed or not. The main goal is to match the groups which are used in Nextcloud to the NFS for fear ACLs which we are using in the campus file system. My colleague Gregor will talk about that in the next talk. So this was my part. Thank you for your attention. If you have any questions, remarks, or just want to talk, please come to me. Thank you.