ken-ji

Sorry if it wasn't clear (or I omitted the info) With the share set to "Private", the default rule is *(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash) When you set something in the rule field, that rule takes over and the default is completely superseded. So in my previous post, there are two rules stated in the field. one for 192.168.2.* the next for * (everybody else) If you omitted the second rule, everybody would get access denied.

Here's a sample that will only allow the 192.168.2.* machines write access to the NFS share. Everybody else gets readonly Additionaly, the options allow root user access from the 192.168.2.* machines. Everybody else gets mapped to uid=99 192.168.2.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash) So, if the client IP fails to match whatever you have listed, they don't get access.

This works both ways. Just be careful to use a cache-only or share-only location with the Dropbox mount point.

Ok , but the Docker data folder should be cache only... or array only. Otherwise Dropbox will delete your files when the mover kicks in...

That's a permission issue, but AFAIK with no way to isolate which file dropbox is having issues with.

Refer to this topic as this explains the correct way of using the Private NFS shares

Right, the permission issues is actually due to some missing libraries. The container is using Slackware as the base OS after all. I've pushed out the necessary change to correct the missing library issue, so the docker should work again. However, the account linking issue is still there AFAIK, and I"m still looking for a way to consistently replicate the problem so I can fix it.

Sorry to hear you couldn't solve the permissions issue. I haven't had time to work on this, as the dropbox app it self operates rather mysteriously and keeps dropping the account authorization every unraid startup. When my personal life settles down I should be able to work on this some more.

Yes. Typically you will only need rw or ro

well by default the shares are still mountable, they will just be read-only shares. The rules will allow you to grant write access to certain machines.

NFS does not have concept of passwords for security. it relies on network ACLs and filesystem ACLs Security = Secure make eveything readonly Security = Private requries a rule to allow a machine to read and write (cf the linked post). A rule can also be set block access Finally the mounting machine will send the accessing userid and groupid to the server, which will then do a regular filesystem ACL check to determine if you can read or write to which files and directories.

Hmm. Kinda assumed those were set since you were running a VM/container host under a hypervisor. But yeah. that's the last thing most people will think off.

Can you also show the outputs of docker ps -a and docker exec [container] ip route The errors seem to be related to something else. Also, your unraid server is in the same group of addresses you told docker to use. This is not a problem yet, but could be when something decides to use the same address by chance (unless all your dockers will have static ips)

Is that a UD bug/limitation, about the complex password issue, I wonder.

Did you try mounting the synology shares using the IP of the synology rather then name? ie //xxx.xxx.xxx.xxx/Movies I ask because unless you have an internal DNS resolving the name NAS to the IP, smb mounting by name get a little weird at times. Windows does the resolution with some helpful side channels, but it will drive unsuspecting users up the wall if you are not aware of it.

Wait, I thought both /var/log and /tmp are both tmpfs with the same size initially?

This particular NGINX docker is supposed to do the SSL part for you and reverse proxy connections in so that accesses to the service is SSL'd with an auto renewing certificate from Let's Encrypt service. As far as the proxied web app is concerned it is not using SSL.

Well if there was a vulnerability in NGINX, it could be a point of attack. That said, you only expose the stuff you want to be external facing if you must, and use VPNs to access anything else. My config by the way is internal facing. A separate config (with SSL) and separate DNS names is used to "isolate" public facing services.

Drop the listen lines, and just use server_name ones server { listen 80 default; root /var/www/default; } server { listen 80; server_name mediastore; server_name 192.168.2.5; location / { proxy_pass http://192.168.2.5:8080; } location /transmission { satisfy any; allow 192.168.2.0/24; auth_basic "Transmission Remote Web Client"; auth_basic_user_file /config/transmission.passwd; proxy_pass http://192.168.2.5:9091; } location /kibana { proxy_pass http://192.168.2.5:9000; rewrite ^/kibana$ /kibana/ permanent; rewrite ^/kibana/(.*) /$1 break; access_log off; } } Here's mine, where I proxy unRAID WebUI (on 8080), Transmission on 9091, and Kibana on 9000. my unRAID is on 192.168.2.5 and note that I don't listen on a specific IP, just setup valid server_names to use and an empty default (kinda jail)

If 192.168.1.82 is the IP of you're unRAID server, you are doing it wrong. a docker container gets its own IP in a totally different subnet and its dynamic depending on what oder the container gets started up You should make the nginx configuration be the default_server (ie any interface IP), that way it don't care about this detail.

Oops. just noticed now the wrong capitalization in the post. Corrected.

@Squid I'll add that as part two.

Why can't I delete a file (without permissions from root/nobody/Unix user/999/etc)? My VM/Docker created some files but I can't access them from Windows? First a primer: Unix filesystem permissions/ACLs (access control lists) in a nutshell There are always 3 permission groups (owner, group, other) owner - if you own the file, these permissions apply group - if you are a member of the group, these permissions apply other - if you are not the owner or member of the group, these permissions apply Permissions are cumulative, there is no "deny" permission, so if one group grants permission, permission is granted. You can easily check the permissions of a file from the shell with root@Tower:~# # ls -l /mnt/user0/slackware/ total 92 -rwxr-xr-x 1 nobody users 410 Aug 10 2016 getall.sh* -rw-r--r-- 1 nobody users 5336 Oct 29 15:20 mirror-slackware-current.conf -rwxr-xr-x 1 nobody users 39870 Nov 30 2013 mirror-slackware-current.sh* -rw-r--r-- 1 nobody users 5397 Oct 29 15:20 mirror-slackware.conf lrwxrwxrwx 1 root root 27 Jan 28 2016 mirror-slackware.sh -> mirror-slackware-current.sh* drwxrws--- 1 root root 56 Jan 16 2014 multilib/ -rwxr-xr-x 1 nobody users 7165 May 20 2010 rsync_slackware_patches.sh* drwxrws--- 1 root root 4096 Jun 11 2015 sbopkgs/ lrwxrwxrwx 1 root root 16 Jan 28 2016 slackware64 -> slackware64-14.1/ drwxrws--- 1 nobody users 4096 May 28 2016 slackware64-14.1/ drwxr-xr-x 1 root root 4096 Dec 5 02:00 slackware64-14.2/ drwxrws--- 1 root root 4096 Aug 11 2016 slackware64-14.2-iso/ drwxr-xr-x 1 nobody users 4096 Dec 5 02:01 slackware64-current/ drwxrws--- 1 nobody users 4096 May 1 2015 slackwarearm-14.1/ The permissions are the displayed with the 10 character string at the start of the line [l][rwx][rwx][rwx] the first character just tells us the type of the file/directory/link we are working with the first triad are the owner permissions, these are the permissions that apply to the owner of the file/directory/etc the 2nd triad are the group permissions, these are the permissions that apply to the members of the group of the file/directory/etc the last triad are the other/else permissions, these are the permissions that apply to users who are not the owner nor members of the group of the file/directory/etc For files: To read a file: read permission is needed. r-- To write a file: write permission is needed. -w- To execute a file (as a script, or binary): execute is needed. --x For directories: To list the contents a directory: read and execute is needed. r-x Weird things happen otherwise To create/delete files in a directory: write is needed on both the file and the directory. -w- Example: So for a file /mnt/user/share/a/b drwxrwxr-x 1 nobody users 2 Mar 15 11:57 a/ -rw-rw-rw- 1 nobody users 2 Mar 15 11:57 a/b Other than root, nobody or members of users. the file b would be impossible to delete, since the write permission to the directory is missing. The file however, can be overwritten by anybody. Now, Windows access to the files is over SMB SMB has two modes of access to the file. samba is the app providing the access. Public/Guest access - (unRAID default) in this mode, all access is allowed. There are no passwords needed. Files and directories are created with the nobody user. Permissions are typically set to rwxrwxrwx which grant anybody read and write access Private/Secure access - in this mode, users need to be defined and passwords assigned. Files and directories are owned by the user who created them. But when a share is created, unRAID assigns it to nobody with full read, write, execute for all (owner, group, and others).(ie drwxrwxrwx) The problem begins when there is a VM, docker creating files. Lets say the VM is using the user backup. Lets say user alice is trying to delete the old backups from her Windows PC. Even if the shares are public, she would hit the error about requiring permissions from backup to delete the files. Why? Because samba will be using the user nobody to delete the files made by the backup user, and typically the file permissions won't allow it. If the shares are private/secure, it can still fail because alice user is not the same as the backup user, and thus the permission problem exists again. (There are cases where this is not true, but that's a bit outside the scope of the FAQ) How do we correct the issue The easiest way to correct the issue is to run Tools|New Permissions which pave over all of the shares and disks to have files with rwxrwxrwx permission and ownership by nobody. But now we don't want that since our VMs and dockers are, in effect, separate OS with their own users, which may or maynot coincide with the new attributes. So, we login to the terminal (over SSH or console) and from the terminal, we run: root@Tower:~$ chmod 777 -Rv /mnt/user/<share1> /mnt/user/<share2> ... This will cause all the permissions of the affected shares to be set to rwxrwxrwx which should normally fix the issues. In case you have more complex settings or requirements, feel free to discuss them in the forums as this requires case to case settings that might be applicable to your specific scenario. Initial stuff, will expand as needed

New udev rules can be loaded in run time with udevadm trigger, so fixing your device to a specific devicename could work.

That's odd. Did you update the docker image? Dropbox is supposed to upfdate itself and the image is designed to allow it to. You don't need to restart it. Maybe your base image is too old now and it needs to be updated.