explosionhole

bumping this, after submitting nearly a full day ago. why is a Nginx process starting up outside Unraid? Can I kill it? What created? I just want my containers back..... 😢

I clicked the Update notification in the UI for 6.12.2. It seemed to complete ok and rebooted. Docker is running. I have a core set of containers for data storage and network routing. The MariaDB container auto-starts. I use Nginx Proxy Manager for network routing between containers. This does not start and produces the error of this thread. If I drop into the Terminal, `netstat -anop | grep 443` returns: tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 2516/nginx: master off (0.00/0/0) tcp6 0 0 ::1:443 :::* LISTEN 2516/nginx: master off (0.00/0/0) Why is there a process outside of Unraid running, as it will block my ability to use this port within Docker? Can I stop it? If so, how? There aren't any config settings for this in the standard UI. If it is erroneous, how might it have got there? I am human, therefore prone to error. I can't rule it out.... I expect that freeing this port will allow NPM container to start, which in turn will allow the others. Is this sensible? Attached the diagnostics. tower-diagnostics-20230705-2341.zip

Got this up and running, as I had expected... The end-user request would look like `https://full.domain.name/webdav`, so for Seafile config of the WebDAV component is in a file (specified within the Seafile container config) `<seafile-data-location>/seafile/conf/seafdav.conf`: [WEBDAV] enabled = true port = 8089 share_name = /seafdav On the NPM side, as it is a "route" rather than an entirely separately hosted solution it needs a "Custom Location", inside the existing Proxy Host for the above site, that points my `full.domain.name` to the internal container's point, in my case" `http://tower:8082`: Location: `/seafdav` Scheme: `http` Forward Hostname/IP: `tower` Forward Port: `8089` (from above config file)

So the basis of choosing another proxy host, rather than redirection host, is the use of a different endpoint / port? Thanks for that nugget. Given that this is all hosted within a single container, which may have different ports exposed, I wasn't sure how NPM interacted with it. Their documentation states to not use "/" behind a proxy, as this is already configured for the main app routing. But I haven't tried it - querying the community if there is prior experience. So I will try with my existing path first. Can re-deploy the containers with the other config.

Can someone help with the best implementation for Seafile's WebDAV configuration please? https://manual.seafile.com/extension/webdav/ I have the seafdav.conf file in the right location, using "/seafdav" as my share name / path. I use Nginx Proxy Manager in-front of the Seafile container with my custom URL as a Proxy Host. How do I add in the extra Nginx config? Should this be: A "Custom Location" inside the Proxy Host config? A new Proxy Host? A new Redirection Host?

this is my `script` syntax: #!/bin/bash #foregroundOnly=true backgroundOnly=true arrayStarted=true #name=blah blah blah #argumentDescription=This is the description of the argument(s) #argumentDefault=defaultArg1 defaultArg2 etc docker exec mariadb sh -c 'exec mysqldump --all-databases -uroot -p"password" | gzip > /mnt/backups/unraid_`date "+%d-%m-%Y"`.sql.gz' find /mnt/user/data/Backups/mariadb/ -type f -mtime +15 | xargs rm

I cannot see any difference in punctuation from the default provided scripts. File permissions are the same. I had to debug it by re-running it while editing the script, but it executes now.

Installed the User Scripts plugin, and followed the usage / guides to populate the various files. After adding the script and executing it, I cannot now run in the background or schedule it for future runs. Is this a known issue? Is there a fix?

Installed the User Scripts plugin, and followed the usage / guides to populate the various files. After adding the script and executing it, I cannot now run in the background or schedule it for future runs. Is this a known issue? Is there a fix?

I deleted all of the mounts and directories on the Unraid server and inside the MariaDB container too. Then recreated it, and seems to be working as above. Not sure which permission was causing the issue, might have been the first output file and afterwards the script would need to update an existing file.

I know this. What I don't (off-hand) understand is the user and permission model for Unraid with Docker containers. If this was a pure Docker (or other container platform), I would use newer "volumes" not "bind volumes". However, adopting to a new platform, I am trying to follow the typical patterns that follows the Unraid GUI.

thanks for the pointer. when selecting the deployed Mariadb-Official container, so view it's config it actually lists a command to perform backups, which they have as: docker exec MariaDB-Official sh -c 'exec mysqldump --all-databases -uroot -p"YOUR_ROOT_PASSWORD"' > /mnt/user/Backups/all-databases.sql Which I tried, by adding a new "bind" volume to the container's config and pointing the paths. Now I get "permission denied", presumably the local user this is running as within this container doesn't have permissions to my new "bind" volume. I cannot identify which user I am on the container's console. docker exec mariadb sh -c 'exec mysqldump --all-databases -uroot -p"YOUR_ROOT_PASSWORD" | gzip > /backups/unraid_`date '+%d-%m-%Y'`.sql.gz'

I have installed the user.scripts plugin, which is very useful, and have copied across a backup script (originally written for MySQL, but reusing here for my new MariaDB docker container). It errors with: /tmp/user.scripts/tmpScripts/mariadb-backup/script: line 11: mysqldump: command not found Under which environment and user is this executing? I am assuming on the Unraid's OS itself and as `root`.

Spent an hour on the phone with Apple Support. Ended up talking this through with a "senior engineer" from a Photos.app specialist. Apple do not support network-attached storage for the Photos app. I could submit this as a new feature request. So I need to ask among the Unraid community, if people have this setup and similar size library sizes? (c.300GB) Or do Mac users prefer to keep Photos with "local" storage (USB or internal)?

oh no - this is terrible news! and I fear for any promptness in getting this resolved in acceptable timeframes, if ever! what alternatives are there with Unraid? Are any of the native photo library apps any good? with Mac compatability? Otherwise is the recommendation to keep using local disks?

I have a 300GB Photos library. I have until now used this with locally-attached USB drives, with an APFS formatted partition. I do not like the inconvenience of connecting, mounting and being tethered to this physical device. I would also prefer to centralise this on my Unraid instance, that can also be included in my offsite backup config. However, it crashes every time. The source bundle has been successfully copied to Unraid, via SSH / SFTP using `root` user, and then correcting the filesystem permissions. After this, holding down Option key while starting the app allows me to select which Photos library I would like to open. I choose the new copy on the SMB share. It takes a long time, but errors. I have now twice used Control + Option, which enables a repair of the library. This still crashes. Can I ask for any help please? I have attached the latest crash log. It doesn't mean much to me, and I cannot see any obvious errors... Unraid Open SMB Photos library.txt

What is the preferred method to have a new volume to mount to newer versions of macOS (Ventura, 13.x+)? This would be used to host my iTunes / Music and Photo libraries using a network-mounted volume. I can add new music to it, as well as play from it from Apple TV's in my house / network if it is running on my MacBook. The same with Photos. I can add this location to my Unraid's offsite backup as well.

I am also having this same issue, and have not found a published solution or thread that discusses this. Initially, I deployed the 2 containers on the default "bridge" network. Connectivity from the PHPMyAdmin container can only use IP addresses here, which causes me a problem with hard-coding. My intention is to have a SINGLE mariadb container, servicing the back-end needs for many other app-based containers. However, in the PHPMyAdmin's config, under "MYSQL_HOST", if I put in `mariadb` it cannot connect. If I put in the assigned MariaDB container's IP, it works. Docker documentation, at this time of writing, states "--link" is deprecated and to use networking configuration to allow this. Using user-defined networks allows name-based resolution as well as IP addresses. This sounds ideal for me! At the main "tower.local" console (from the GUI's top-right options), I issued: docker network create main-net I re-created the MariaDB-Official and PHPMyAdmin containers, both connected to this new `main-net` network. In the PHPMySQLAdmin, I was still specifying "mariadb" (the name of the mariadb container) under the `MYSQL_HOST` field. When I try to connect, it still errors. But if look in the MySQL's log file, I see: Which suggests the correct container (mariadb) IS being hit with the PHPMyAdmin login request. The PHPMyAdmin is specifying the "@'172.18.0.3'" as part of the connection string. To test this, I redeployed the PHPMyAdmin container, hard-coding the `mariadb` container's IP address (172.18.0.2). Now it logs in fine! But I have hard-coded. If I go to the `mariadb` User Accounts section, these are the default users in my setup: I created a NEW user, with a specific "Host name" entry of the PHPMyAdmin container, 172.18.0.3 (to mimic the log file entry I saw). Then I redeploy the PHPMyAdmin container to use the `mariadb` as the MYSQL_HOST entry. Retrying the PHPMyAdmin login, which is now successful. Why is the 'root'@'%' not being applied to my authentication, to cover the scenario of `'root'@'172.18.0.3'`? I thought this was the point of the "%" (basically saying ANY host) configuration?

Some research against the Docker documentation, custom (user) created networks allow for additional container hostname lookups across the network - precisely what I need. at the main "tower.local" console (from the GUI's top-right options), I issued: docker network create main-net I re-created the MariaDB-Official and PHPMyAdmin containers, both connected to this new `main-net` network. In the PHPMySQLAdmin, I was still specifying "mariadb" (the name of the mariadb container) under the `MYSQL_HOST` field. When I try to connect, it still errors and if I look in the MySQL's log file, I see: Which suggests the correct container (mariadb) IS being hit with the PHPMyAdmin login request. The MariaDB user is specifically using the @'172.18.0.3' as part of the connection string. To test this, I redeployed the PHPMyAdmin container, hard-coding the `mariadb` container's IP address (172.18.0.2). Now it logs in fine! But I have hard-coded. If I go to the `mariadb` User Accounts section, these are the default users in my setup: I created a NEW user, with a specific "Host name" entry of the PHPMyAdmin container, 172.18.0.3 (to mimic the log file entry I saw). Then I redeploy the PHPMyAdmin container to use the `mariadb` as the MYSQL_HOST entry. Retrying the PHPMyAdmin login, which is successful. Why is the 'root'@'%' not being applied to my authentication, to cover the scenario of `'root'@'172.18.0.3'`? I thought this was the point of this configuration?

Final research from today... Can I sense check with others how the official docs describe networking? Host use-cases should be tiny, and not for my use-case. I am asking about the service discovery (DNS) part of containers when using Docker with Unraid,

If I hard-code the mariadb container's IP address on the same "bridge" network, it connects. How can I configure this container to use Docker-based DNS to identify the DB container? It should automatically track any IP address changes of the containers themselves. I am sure this is the purpose of the "--network" switch in a `docker run` command is to allow a local-network lookup? Or are extra parameters required?

Are the `'--net=..."` and `"--network=..."` commands the same / equal? I have it in my PHPMyAdmin container, from the output of the Unraid UI to deploy this from the "Apps" repository. docker run -d --name='phpmyadmin' --net='bridge' -e TZ="Europe/London" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="phpmyadmin" -e 'MYSQL_USER'='root' -e 'MYSQL_PASSWORD'='password' -e 'PMA_HOST'='mariadb' -e 'PMA_PORT'='3306' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:80]' -l net.unraid.docker.icon='https://secure.gravatar.com/avatar/4be7d922dc46f22e6b0cf1162f0e329b.jpg' -p '8080:80/tcp' 'phpmyadmin/phpmyadmin' Or is the Unraid not deploying this as I am expecting? If I supply "--network=docker0" (for example), the documentation suggests the Docker Engine provides the ongoing management of container to assigned IP address and publishes it in the local container's `/etc/hosts` file. Or am I missing more config?

In the end, I bought a HPE Microserver Gen8, which I replaced with the highest-recommended spec CPU (4 core, hyper threading), new 16GB (combined), 4x HDD and 1x SSD. Needed Intel CPU for the Docker images. Well designed hardware for NAS purposes. I had loads of trouble getting it deployed, because it uses older BIOS and boot capabilities. Look for my posts! But there is one with the resolution. Only just past this, and into first data copying and container / app deployments on it, so cannot comment on the performance as yet.

Out of the box install, first time trying Unraid. It seems there is a `bridge` network called "docker0". I have created containers from the official `mariadb` and `phpmysql` images, both connected to this default network. In the `phpmyadmin` container, the hostname I put the same container name from the other, "mariadb". It does not connect between them. both have the `--net='bridge'` in their docker run command. Does Unraid have a different approach?

OMG!!! SUCCESS!!! 🎉🎉🎉 #mic-drop! I think it was the use of USB2.0 flash drives to deploy this too, in combination with restricted ability to boot using only the USB2.0 ports. I had to use a Ubuntu Live to boot from, to give me a Linux environment that I could run these commands on. This needed a USB2.0 device. I had previously then been using a USB3.x (tried 3.1 and 3.2, given what I had to hand) to install UNRAID onto. I thought I had booted from one of these USB3.x devices - but I expect I was getting confused with the combinations I had been trying. So re-create the partitions on the USB2.0 device from the `fdisk` commands in the first link. Once the `mkfs.fat` command is issued and the /dev/sdX1 has been labelled as "UNRAID", I switch to the second link, to install Grub. I actually swapped between both guides here actually, and installed all 3 `grub-install` configs (just in case!). Now I have my FIRST booted unRAID running, I now have to learn how to use it! Thanks so much for people's inputs and trying to inform and guide me. It was all appreciated!