This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ====== H) File Server ====== I will not discuss how to share your files on the home network using __legacy__ tools like [[https://it.wikipedia.org/wiki/Network_File_System|NFS]] or [[https://it.wikipedia.org/wiki/Samba_(software)|SAMBA]], there are plenty of tutorials online and, beside, it's kind out of the scope for self-hosting. I will focus on how to provide access via __web browser__ and via __WebDAV__, which is a web-based sharing protocol a bit like NFS or SAMBA, but aimed ad broader //in**ter**net// access, and not //in**tra**net// access. The idea is to create share areas where your users will be able to store files. It is possible to extend this idea also to user-specific areas where each user can put private stuff not visible by other users, but this require a little bit extra complexity and might be addressed in the future. You will be using your SSO authentication, there will be no need to create new users anywhere, and it will of course be protected by the Reverse Proxy for external access. In the past i used a more complex solution leveraging more tools. That obsolete solution has been moved, for reference, [[selfhost:obsolete:fileserver-legacy|here]]. ===== Overall Architecture and Shares ===== This solution leverages the use of one tool called AList (installation & configuration instructions [[services:alist|here]]). AList is a pretty neat open source tool which is capable to provide, at the same time, both a browser-based solution and a WebDAV solution to access your files. AList itself also support SSO integration, opening the way to provide also a public sharing approach, if needed since the SSO should not be enabled at reverse-proxy level. You can also define as many shared folders as you like, and even connect to remote services from the same UI. I will assume that your shares are under **/data/shares**, but of course each share can be located anywhere you like. Let's also assume, as an example, that your share is called __/data/shares/common__ and is managed by the user __fileserver__ of the group __users__. The requirement for users and groups will be detailed later on. Each share folder will have the following structure: * /data/share/common/ * /data/share/other_share/ * /data/share/another_share/ Your AList installation will provide WebDAV and browser access from one single port hwich need to be reverse-proxied. I choose to assign a dedicated subdomain, **drive.mydomain.com**, as file server and organize the shares like this: * **https://drive.mydomain.com**: will show a main login page to access all the shares * **https://drive.mydomain.com/common**: direct browser access URL for __common__ * **https://drive.mydomain.com/webdav**: WebDAV access URL for all the shares * **https://drive.mydomain.com/webdav/common**: WebDAV specific access URL for __common__ * **https://drive.mydomain.com/dav**: WebDAV access URL for all the shares * **https://drive.mydomain.com/dav/common**: WebDAV specific access URL for __common__ I think that /webdav is easier to remember than /dav, but AList by default shared WebDAV under /dav, NGINX will be used to map the /webdav path to /dav. You can add any more folders as separate shares as you like. Due to how WebDAV works, it is mandatory to separate the browser accessible URLs from the WebDAV ones, like i did above. === Permissions and Users === (Note: you should run AList as the user **fileserver** and group **users**) I assume you have already created the user **fileserver** when installing AList. You need to set the //umask// for the fileserver user to **0002** so that any new files created by it will be writable by the users: <code bash> mkdir /data/shares mkdir /data/shares/common chown fileserver:users /data/shares </code> ===== Fileserver access via Browser ===== Nothing extra needs to be done except install AList, and adding the new shares inside it's WEB configuration. ===== Fileserver access via WebDAV ===== __NOTE:__ using HTTP will cause a 301 redirect to HTTPS, and WebDAV clients will fail. So use HTTPS URL in webdav clients and not HTTP. The only chnage you need to make is to add the following location to the NGINX configuration file you created during AList setup: <code> location /webdav/ { proxy_pass http://127.0.0.1:5244/dav/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; proxy_redirect off; client_max_body_size 20000m; } </code> which will remap /webdav to /dav
