ken-ji

A slightly better way to maintain the keys across reboots is to * copy the authorized_keys file to /boot/config/ssh/root.pubkeys * copy /etc/ssh/sshd_config to /boot/config/ssh * modify /boot/config/sshd_config to set the following line AuthorizedKeysFile /etc/ssh/%u.pubkeys This will allow you to keep the keys on the flash always and let the ssh startup scripts do all the copying.

I'm not sure what the exact problem is, but have you tried starting completely over? the fact that the files are still owned by nobody instead of what ever you set in the environment variable indicates something is wrong. Also see if the docker logs have anything in them. (Same place where you see the login/authenticate link)

Basically, there are some points to be considered. The template hasn't been updated to 6.2 thus the variable descriptions are of no help. (I'll get around to that soon) The environment variables pertaining to USER/UID/GROUP/GID are set to acceptable defaults for normal/general use case of unraid. These variables should only be set at the very start of the docker, or if you know exactly what is going to happen. If access to unraid is via user accounts and not the default public access, by default files would then need to be accessible for RW by the user. Let us assume that your user "seth" has a uid of 1000. Thus that means that DROPBOX_USER = "seth" and DROPBOX_USERID=1000 Upon start, the docker will attempt to change the permissions to this user. and then start the docker process under this user. The fact that your files are still owned by nobody shouldn't be the case. Also, the Dropbox share should be either cache only or array only. As some users have experienced, placing them in a normal share is a disaster waiting to happen once the mover works, Dropbox thinks your files were deleted and thus proceeds to nuke your files. I've run this before from a very clean slate and always my files are pulled from the lan and network.

This could be doable if LT would ship the qemu arm emulator as well. A quick peek only shows the binaries for x86_64 (not even i386) so on ly 64bit x86 VMs

No, you don't need to modify the app to get it to run in Docker. you just need to think a little differently. Docker just doesn't provide you with the usual scaffolding (init or [heaven forbid] systemd) but init is replaceable with shell scripts and the ever true and tried while true; do sleep for_a_time; done loops. Last two lines in the app script for my dropbox docker which fully supports auto updating. su -l ${DROPBOX_USER} -c "/dropbox/.dropbox-dist/dropboxd" & while true; do sleep 86400; done

And I'll reiterate that we should have a early package/patching system for emergencies or situations like this. I understand and appreciate the appeal of an ramdisk based OS (very easy to fix any problems), but we really ought to be flexible too and allow broken/breaking stuff to be patched. and the easiest is a directory for packages of stuff from Slackware or LT to be applied early in the boot process.

sysctl is never run inside the docker; should be done on the host side. If you are getting this error running docker, considering adding the following to the /boot/config/go script near the start # configure sysctl /sbin/sysctl -p /boot/config/sysctl.conf then create a file /boot/config/sysctl.conf with contents fs.inotify.max_user_watches=100000 you can use this in the cli to set and check without rebooting root@Tower:~# echo fs.inotify.max_user_watches=100000 > /boot/config/sysctl.conf root@Tower:~# sysctl -p /boot/config/sysctl.conf

A different tip some users might find useful: Setting the shares to private enables authentication, which requires unraid users to be defined. By default, SAMBA shares that have authentication uses the user who authenticated to perform the file access. this can cause file permission issues between multiple users, particularly between files created by dockers, and unraid users over SMB shares. A workaround is to force all behind the scene access using a single user, typically nobody. Then using the unraid user accounts for authorization only. I have this little snippet in the /boot/config/smb-extra.conf Code: [global] force user = nobody There are other options to force permissions too, but its not necessary as the nobody user will always have access to files created, modified by it self.

Ok. Small tip for RobJ: I want all of my syslogs redirected to a ELK (elasticsearch/logstash/kibana) instance for easy checking and log aggregation. so I inserted this into my go file: echo "*.* @@192.168.2.5:514" >> /etc/rsyslog.conf /etc/rc.d/rc.rsyslogd restart which will make any syslog entries from this point on visible in my ELK instance. If my php skills were any better, I could make a plugin to disable telnet and ftp via the WebGUI

Thanks!

Thanks, I made a correction and used your dmesg file to verify the correct operation. Update is available thru plugins manager. Thanks. I do have a small request regarding the dynamix plugins whatever build environment you are using to building your packages (the txz files installed by the plugins themselves), there is slight problem with them that is causing me a bit of grief. root@MediaStore:~# tar tvf /boot/config/plugins/dynamix.schedules/dynamix.schedules.txz drwxrwxrwx root/root 0 2012-09-28 20:22 ./ drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/ drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/ drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/ drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/plugins/ drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/ -rwxrwxrwx 0/0 122 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/default.cfg drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/icons/ -rwxrwxrwx 0/0 3231 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/icons/fixedschedules.png drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/images/ -rwxrwxrwx 0/0 3220 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/images/dynamix.schedules.png drwxrwxrwx 0/0 0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/include/ -rwxrwxrwx 0/0 1489 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/include/update.schedules.php -rwxrwxrwx 0/0 198 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/README.md -rwxrwxrwx 0/0 3532 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/Schedules.page The permission of the ./ (root) is just wrong - it should be 755 not 777. (this is biggest WTF) This little oversight is causing SSH to reject my keys as they are considered insecure and just bother me with a password request. (this will cause any of my batch scripts to fail as ssh keys are the only way to do batch commands over ssh) In fact I think only your plugins have the wrong permissions (at least the ones that I use) Keep up the good work!

Any chance you can share your dmesg file? Attached. dmesg.zip

The latest Dynamix System information is a bit broken on 6.1.9: It tries to show the P +Q algorithm and mine comes up ( + unknown /var/log/dmesg has this: raid6: using algorithm sse2x4 gen() 10409 MB/s raid6: .... xor() 8128 MB/s, rmw enabled

I've never had to do anything about permissions - so something's up and incorrect... hmmm... your app folder is owned by root? are you sure your DROPBOX_USER and DROPBOX_USERID are correct? they default to nobody and 99 and if i remember your issue from before, you were trying to have the USERID set to 1000, so the directories should be owned by zan user?

Unless you are using nfs mounts of the same shares and expect to have the files owned by the local user. Shouldn't be much. I've seen this scheme used in some commercial NAS OS and NAS distros. (Openfiler I believe)

Yes, I see the problem. It seems the docker technology is preventing updates. I happen to have a headless server installed with dropbox so I can see the upgrade issue. I've upgraded the docker image now with dropbox 4.4.29, and will work on this over the next few days. This is the latest that we can pull from the dropbox download links. but my headless server has 5.3.29 so I think auto upgrading is getting broken by the way a container works.

Well yes and no. the client is the headless client. so there's really nothing to see. On the other hand, it is possible to run some shell commands to see the client as it syncs. (but nothing more) from the unRAID ssh/telnet shell # docker exec -it -u nobody Dropbox /bin/bash -l nobody@abc5221e:~/ $ cd Dropbox; dropbox.py <subcommand> one of the commands is ls (or filestatus - don't remember which) it will return the list of files as they are syncd. Anything more monitoring is beyond the client (or my meager skills)

Just pushed out an update of the Dropbox docker. Let me know if you still have issues.

I'll have a look. Because it seems the Dropbox client seems to have stopped updating.

I can only speculate, but this might be an issue with the dropbox client in the docker (something went corrupt or awry). Try deleting the docker and all the files/folders used by the docker (the three mapped directories). Don't attempt to save/reuse anything as that might make the dropbox client think you deleted everything and proceed to flush your account.

Good point. Let me amend the request as I didn't think I meant a forced change with the request.

Just to inquire why do you not want it. As a long time Samba Fileserver administrator, I've always seen that for most users, the simplest case of user accounts for authorization is sufficient as a default. Advanced users should of course be allowed to disable this setting (or set a different one per share)

Hi, Would like to request that the WebUI setting be added to enable/disbale the setting of [global] force user = nobody force group = users or [share] force user = nobody force group = users What this option does is that all access done over SMB (on a specific share is desired) will be done via the nobody user and the users group, regardless of whether the share is public or private. This allows dockers to run as one specific user (nobody) and group (users) with minimal permissions issue. The New Permissions tool already sets everything to that user and group so why not set everything to be generated with this user and group by default. Additionally, the users created for unRAID becomes simple authorization accounts and are never related directly to file access. Making this user configurable as to who the user and group are will make it even better, as some dockers and plugins can still run as a different specific user and the clients would not even need to be aware of this. Of course, I'm not sure how this could be enforced for NFS and AFP shares, but I'm sure these users know what they are dealing with. I've seen this done in some of the other Linux NAS distributions (Openfiler was one of them I think) Edit: Changed request from a default setting to a possible user option.

I'm a little stumped by your issue. You've reset permissions. Did you do the force user setting i suggested? Did you reset the ownership of the dropbox config folders? Could you post a screenshot of your Docker configuration?

One suggestion I can give you is to put this inside /boot/config/smb-extra.conf [global] force user = nobody Then run the Tools | New Permissions to reset all the permissions and ownership to nobody:users (if they aren't already) At this point starting and stopping the Array will ensure that all your SMB access is now via the nobody user. Then just install the Dropbox docker. There should be no need to configure the DROPBOX_USER variable.