ken-ji
Members
-
Joined
-
Last visited
Everything posted by ken-ji
-
@Gico Do you know which client on your network is 192.168.168.10? its connecting to your server repeatedly via /login and nginx is complaining about it.
-
No these are host keys - what the server uses to identify itself to the user - and all the files in /boot/config/ssh will be installed into /etc/ssh upon startup of the ssh server. If the ssh server starts up and cannot find these host keys, it will generate new ones and scare anybody trying to ssh in with a warning message about possible Man in the Middle Attacks due to host key mismatch. Needless to say, the new ones will be saved to /boot/config/ssh as well. For those who use the ssh plugin or know what they are doing, the configuration of the ssh service can be changed and persisted by copying the modified /etc/ssh/sshd_config file here.
-
Don't touch those as they are the SSh host keys (deleting them will regenerate them on sshd restart) If they are regenerated, you'll get warning about Man In The Middle attacks (ssh will consider your Unraid host as never before seen)
-
Well as it stands, you should enable root as that's the supported unraid way.
-
well there's currently some code in /etc/profile that actually prevents non-normal users from getting via ssh (rather you can't spawn a login shell without encountering issues) so I think a review of the multi user stand of unraid vs your needs is in order. (I'm not advocating either way, just that there shouldn't be changes that break standard functionality)
-
Upgraded from 6.9.0 and seems to have resolved the issues with 6.9.0 There some things that could still use fixing, like /etc/profile forcing bash to start in /root, which breaking some of my tmux scripts Also, I personally don't think its neccessary to force 777 access to the ./dev/dri, but I understand why you would want to take the easy way out and make things easier for users. Though it should be up to the docker image creators/maintainers to account for this. It simply is not the Unix mentality to just willy nilly assign all access to entire directories (I'm looking at the default/recommended Unraid file permissions) nor is it a good security practice.
-
Everything in /boot/config/ssh/root is now accessible as /root/.ssh so just keep the authorized_keys file in /boot/config/ssh/root and no need to manually copy them over or set permissions
-
Easiest is to use a lockfile (or semaphore) Near the start of the script if [ -e /var/lock/script.lock ]; then echo "Still running" exit fi touch /var/lock/script.lock Then at the end of your script rm -f /var/lock/script.lock
-
Would also be helpful to note that ( used / avail ) is not quite what you want as while used increases, avail decreases. You want used / size #!/bin/bash thresh=70 stats=( $( df --output=used,size /mnt/cache | tail -n 1) ) percent=$[ 100 * ${stats[0]} / ${stats[1]} ] [ $percent > $thresh ] && sh /usr/local/sbin/mover
-
Attempting to start bash shells in specific directories under tmux fails. Upon investigating it seems these lines in /etc/profile have cause all login shells to forcibly open in /root # limetech - modified for unRAID 'no users' environment export HOME=/root cd $HOME This didn't occur in the last stable version 6.8.3 or earlier. Workaround is to edit the /etc/profile to remove the offending lines. I don't understand the rationale behind this.
-
Odd. I've never seen any transcoding files - I'm transcoding to RAM vi a mounted directory under /tmp - unless I look while someones actively playing something. So I've never this issue.
-
or you have a properly defined plugin being installed after this one.
-
I took a lot at the Parity Check Tuning Plugin and it was packaged with the nobody:users for all the files including / Slackware packages are simple tar files applied to root and the ownership and permissions of the folders will override the system one. I think If you rebooted now, you'd find yourself unable to ssh in @itimpi You should fix this by packaging as root with the correct permissions
-
You are going to have to check each and every single plugin you have installed. Some of the plugins have incorrectly packaged files that muckup the ownership of the / directory. A quickfix if it hits you is to use the Web-based Shell tool to login as root, then poke around with the permissions of the / directory
-
create a test directory in /mnt/user/Downloads root@MediaStore:/mnt/user/Downloads# ls -al test total 0 drwx------ 1 root root 0 Jan 20 23:33 ./ drwxrws--- 1 nobody users 205274 Jan 20 23:33 ../ root@MediaStore:/mnt/user/Downloads# ls -ld /mnt/{cache,user}/Downloads drwxrws--- 1 nobody users 205274 Jan 20 23:33 /mnt/cache/Downloads/ drwxrws--- 1 nobody users 205274 Jan 20 23:33 /mnt/user/Downloads/ when this directory is mounted in a container like so root@MediaStore:~# docker run --rm --name box -d -v /mnt/cache/Downloads:/media alpine sleep 3600 131ed3b6357ba8253513afc5e536361adf39de6ac5ca26ccdf22337770d60c76 root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file' uid=1002 gid=0(root) drwxrws--- 1 99 users 205274 Jan 20 15:33 /media touch: /media/a_file: Permission denied root@MediaStore:~# docker stop box box root@MediaStore:~# docker run --rm --name box -d -v /mnt/user/Downloads:/media alpine sleep 3600 0dc76c0b4c8c6cf3f7b05c998a96e96a18e6f394e0e0bada60b66db3225c17c8 root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file' uid=1002 gid=0(root) drwxrws--- 1 99 users 205274 Jan 20 15:33 /media -rw-r--r-- 1 1002 root 0 Jan 20 15:40 /media/a_file root@MediaStore:~# docker stop box box Seems like when the path is mounted via the user share path, the file permissions can be ignored in a specific situation Edit: It seems to be shfs itself - since the following issue occurs at the Unraid level root@MediaStore:/mnt/user/Downloads# echo x > a root@MediaStore:/mnt/user/Downloads# chmod 600 a root@MediaStore:/mnt/user/Downloads# ls -l a -rw------- 1 root root 2 Mar 23 21:44 a root@MediaStore:/mnt/user/Downloads# ls -l /mnt/cache/Downloads/a -rw------- 1 root root 2 Mar 23 21:44 /mnt/cache/Downloads/a root@MediaStore:/mnt/user/Downloads# cat a x root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh nobody@MediaStore:/mnt/user/Downloads$ cat a x nobody@MediaStore:/mnt/user/Downloads$ cat /mnt/cache/Downloads/a cat: /mnt/cache/Downloads/a: Permission denied nobody@MediaStore:/mnt/user/Downloads$ echo y > a nobody@MediaStore:/mnt/user/Downloads$ cat a y mediastore-diagnostics-20210120-2344.zip
-
Sadly I don't have any. Probably should document it for my own peace of mind.
-
Here's what I did in my own system (also behind CGNAT). Spun up a Mikrotik CHR (virtual router) on Linode (but any other VPS with completely unblocked ports is also fine). Made a site-to-site VPN between my home networks (3 different houses) and the VPS. then port forwarded port 80 + 443 to an nginx container (kinda like SWAG - but I prefer to roll my own). This could be done with a Linux VPS, but I wanted to play with a Mikrotik router (all of my edge routers are Mikrotiks) and have less issues with the rather performant IPSec site-to-site vpn This means I can access my Emby server + Transmission container over HTTPS from anywhere. (Added DNS entries at the house with the Unraid server to avoid having to go out and back)
-
Self-signed certs are the CA themselves... unless you are using self-CA signed ones? and I think the browsers will now warn on self-signed certs - even if they were trusted?
-
@theruck for #1, by default the Dropbox data is shared over SMB. the defaults assume you are using Unraid in the default public share mode If this is not the case (you are using user accounts, set User and User ID to the appropriate user) refer to this for more details For #2. Just set the autostart button to on on the Dockers page
-
I'm afraid I have no idea what's going on here. and as you can see from your logs, it contains nothing useful. Only the Dropbox devs probably know what's going on and I don't think they are going to be helpful at all . This headless client is something they are still supporting but they seem to be veering people away from it as its not too easy to find on the site anymore.
-
Correct This whole stopping to sync is something I haven't encountered and I have no Idea what's causing it. I only have 3.5G in my Dropbox account and I've never seen it stop syncing. Losing the linked account data yes, but never the hanging on the sync.
-
@jang430 If you haven't figured it out, your go file is wrong it should be #!/bin/bash modprobe i915 chmod -R 0777 /dev/dri # this must be the last thing in the go file unless you really know why # Start the Management Utility /usr/local/sbin/emhttp &
-
Because Dropbox is meant to be run and used by a single user, the container must create files as a single user and any access over Samba/NFS shares must result in the files being owned by the same user or some issues will occur (like being unable to update directories and files modified from other devices) There is a setting you can apply (just not sure how it will mess things up further for you) in Settings | Samba | SMB extras I added under the [global] section force user = nobody force group = users this makes it so that all access to my files over Samba will be done as the nobody user (and the group users - but this is usually not important). Enabling this will probably break any existing share that is Secure, Private or even Public ones - if the files and directories have been created with the existing users you may have defined. (Running either Fix Permissions tools on the affected shares should fix the issue though) You can turn this on and make some tests on a existing share so you understand what it does though, as reversing it is fairly easy by just removing the lines. I was suggesting that Unraid enable this out of the box, but there's no way AFAIK to do it and not cause issues with users who do not want to enable this.
-
This Docker container will run stuff as the nobody user, hence the error message above regarding permissions. Docker Safe New Perms will work until new files get sync'd or updates are made. I'm guessing, but are you accessing the Dropbox share in guest mode (ie its set to Public) while you have a user in Unraid that the Windows PC you have is set to use/match? (Windows Credentials in Settings) If so, you probably want to blow away this container and the appdata/dropbox and Dropbox share/folders (ie really start over) Then when you reinstall the container, before linking to your account, make sure that the user id to run as is set to the user id of your user (the one windows is using to connect to) If you don't know your user id, just open a terminal to Unraid and run this root@MediaStore:~# id username uid=1000(username) gid=100(users) groups=100(users) which is usually be 1000.
-
Hmm. what network is your nginx docker using? and did you assign the IP as well?
