firetime

Thanks for the template! I'm using it as a playout server. I added an auto start so in the event the container is updated/server restarts it will resume the stream on startup. Add a file map to /home/headless/.config/autostart/ and place an app.desktop file in the mapped autostart folder with the following to trigger Xfce to start OBS: [Desktop Entry] Type=Application Name=conky Exec=obs & StartupNotify=false Terminal=false This is coupled with an OBS LUA script I wrote that auto starts streaming and sequences media playback.

Leaving this here for anyone else who may have similar issues: After moving the appdata folder (due to changing cache drive setup) and copying data across, my GitLab-CE was crashing unraid server randomly. On my previous hardware it would hard lock up and become 100% unresponsive. My new hardware would detect the hard lock and auto restart the server causing a parity recheck due to unclean shutdown. By the end it was crashing the server in less than 5 minutes of the docker container active. The fix was to start the container and execute the below command from the unraid terminal: sudo docker exec GitLab-CE update-permissions Container is working fine without crashing. Additionally the issue was likely caused by a recursive permissions command run in the wrong folder. Because of this running New Perms or Docker Safe New Perms from the tools page before the above command is a good idea.

Running the New Permissions utility caused the Shares page to list the folders again and resetting/saving the settings for the folders seems to fix the issue.

Unraid is reporting that there are no exportable user shares. Additionally attempting to connect to the server results in nothing appearing apart from the flash share if I enable it. (same now and before the flash drive format)

a physical disk called temp. It's a single SSD cache used to cache writes to the array. The cache pool named cache is used for docker.img and app data.

Ive wiped the flash (slow format) and redownloaded unraid. re-attached the drives in the same slots to keep my data. Attempting to recreate the shares results in the same behavior and adding shares with a new name results in a box saying the share had been deleted: Sep 12 17:04:54 Tower emhttpd: shcmd (669): mkdir '/mnt/user/test3' Sep 12 17:04:54 Tower emhttpd: shcmd (670): chmod 0777 '/mnt/user/test3' Sep 12 17:04:54 Tower emhttpd: shcmd (671): chown 'nobody':'users' '/mnt/user/test3' Sep 12 17:04:54 Tower emhttpd: Starting services... Sep 12 17:04:54 Tower emhttpd: shcmd (673): /etc/rc.d/rc.samba restart Sep 12 17:04:54 Tower nmbd[13005]: [2021/09/12 17:04:54.242114, 0] ../../source3/nmbd/nmbd.c:59(terminate) Sep 12 17:04:54 Tower nmbd[13005]: Got SIGTERM: going down... Sep 12 17:04:54 Tower winbindd[13017]: [2021/09/12 17:04:54.242177, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Sep 12 17:04:54 Tower winbindd[13015]: [2021/09/12 17:04:54.242175, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Sep 12 17:04:54 Tower winbindd[13083]: [2021/09/12 17:04:54.242185, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Sep 12 17:04:54 Tower winbindd[13015]: Got sig[15] terminate (is_parent=1) Sep 12 17:04:54 Tower winbindd[13017]: Got sig[15] terminate (is_parent=0) Sep 12 17:04:54 Tower winbindd[13083]: Got sig[15] terminate (is_parent=0) Sep 12 17:04:56 Tower root: Starting Samba: /usr/sbin/smbd -D Sep 12 17:04:56 Tower root: /usr/sbin/nmbd -D Sep 12 17:04:56 Tower smbd[13544]: [2021/09/12 17:04:56.412779, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Sep 12 17:04:56 Tower smbd[13544]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections Sep 12 17:04:56 Tower root: /usr/sbin/wsdd Sep 12 17:04:56 Tower nmbd[13549]: [2021/09/12 17:04:56.423385, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Sep 12 17:04:56 Tower nmbd[13549]: daemon_ready: daemon 'nmbd' finished starting up and ready to serve connections Sep 12 17:04:56 Tower root: /usr/sbin/winbindd -D Sep 12 17:04:56 Tower winbindd[13559]: [2021/09/12 17:04:56.462572, 0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache) Sep 12 17:04:56 Tower winbindd[13559]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Sep 12 17:04:56 Tower winbindd[13559]: [2021/09/12 17:04:56.463047, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Sep 12 17:04:56 Tower winbindd[13559]: daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections

Shares do not return in safe mode. Also recreating a share in safe mode results in the same behavior as before (Share is not created and Starting services... is displayed at the bottom) I've since removed most of my plugins but after booting in safe mode and having the issue persist I'm not sure that was required. Docker is still running but all containers are stopped. No VMs.

Was swapping a share from read only to read write for an account and all shares are now gone. Attempting to re-add any shares results in "Starting services..." to appear at the bottom of the web UI and nothing else happens. Multiple reboots have not cleared the issue and nothing concrete seems to be showing in the log. Sep 11 23:58:04 Hearth emhttpd: shcmd (287): mkdir '/mnt/user/TV' Sep 11 23:58:04 Hearth root: mkdir: cannot create directory '/mnt/user/TV': File exists Sep 11 23:58:04 Hearth emhttpd: shcmd (287): exit status: 1 Sep 11 23:58:04 Hearth emhttpd: shcmd (288): rm '/boot/config/shares/TV.cfg' Sep 11 23:58:04 Hearth emhttpd: Starting services... Sep 11 23:58:04 Hearth emhttpd: shcmd (290): /etc/rc.d/rc.samba restart Sep 11 23:58:06 Hearth root: Starting Samba: /usr/sbin/smbd -D Sep 11 23:58:06 Hearth root: /usr/sbin/nmbd -D Sep 11 23:58:06 Hearth root: /usr/sbin/wsdd Sep 11 23:58:06 Hearth root: /usr/sbin/winbindd -D I've found some other topics for missing shared but most are older and attribute the missing shared to Linux kernel bugs. All of the shares folders and the files are still on the server: Diagnostic data is attached. Any ideas? hearth-diagnostics-20210912-0000.zip

Hey thanks for this docker. I just moved everything over from the Apache docker to get https. Everything moved over find apart from my media wiki install. Running the existing install or a new install throws this error page. It states that php is missing XML and iconv. I know that you stated that you left some surplus packages out of this php install to reduce on size but was a little surprised by the XML package being missing. Not sure how pressed you are for size but in theory if you made the php5 folder available people could include the missing packages as *.so files in the php.ini file to keep them out of the docker image.

That tp-link card implements the realtek r8169. I'm not sure if any of the issues still persist but that chip has had a rocky past with less than stellar consistency. It works for some and not others. If you have excess time to tinker you could attempt to use it but in my position dropping the ~$30 to not have to mess with it ever again would be worth it.

You can see up to a 10 fold increase moving to gigabit capable nic. Some unscientific tests on my system show that copying a large file from unraid server to my desktop nets about 110 MB/s. Copying data to the server is about the same I would recommend looking over at the hardware board for nics that people have had good luck with however just about any Intel branded network card should work (PCI, PCI express x1). They often have the least issues when it comes to compatibility and have good performance. Also you are correct in that the on board nic is still out. From some old posts the Qualcomm Atheros AR8171 that your mother board uses is unsupported.

Another +1 for this. Just spent most of today trying to patch out ipv6 in a mail server docker.

That is a very cool looking motherboard. It's a shame that it seems that every version of that board that supports IPMI they swap out two sata connections for the M.2 slot.

Ha well It helps it's in the basement just off the floor. Also the power bill is split three ways so it's not too awful.

Should be around 19.5°C ± a degree as this fridge thermometer has some large graduations.