Unrayed

The solution to this lied with the fact that SWAG no longer respects that root/cron file without the cron docker-mod installed. Info and solution here, confirmed as working as required now - https://github.com/linuxserver/docker-mods/tree/universal-cron

Just on this, I don't seem to have a le-renew.sh file in my Swag files anywhere in appdata/swag....is this normal or has something maybe been lost from my installation?

I'm having an issue whereby my certs are no longer auto-renewing. I had the cron set for 20:30 each night to check and renew if necessary, but for whatever reason, it recently stopped using the specified cron time and is now using the default 2:08am time (a time that my server is powered off.) Appdata/swag/crontabs/root: 30 20 * * * /app/le-renew.sh >> /config/log/letsencrypt/letsencrypt.log 2>&1 cronjob running on Mon Nov 20 20:30:00 GMT 2023 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/mydomain/fullchain.pem expires on 2024-01-14 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - <-------------------------------------------------> <-------------------------------------------------> cronjob running on Tue Jan 2 02:08:00 GMT 2024 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/mydomain/fullchain.pem expires on 2024-03-26 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^^^ You can see here that things USED to run normally for me at 20:30, but more recently it's back to 02:08 and the cron time specified above isn't being used. Has anyone ANY idea how to fix this? I really don't want to wait for cert expiry reminder emails and then have to manually renew them with certbot. Would appreciate any help, thanks

Perfect, leave it with me for a while and I'll try grab a small ssd from somewhere. Thanks for all your help with this

I'll have to find something. How would I go about this, in terms of my current cache being a dual drive btrfs pool and a theoretical replacement/test drive likely being much smaller in capacity and only being a single drive?

Ok tried disabling each of the drives and performing an SMB transfer of a 5GB file from W10 to Unraid. With the 870 disabled, the file transferred at an inconsistent ~50/70MB/s. With the 860 disabled, the exact same file began transferring at full 113MB/s, but after about 2GB of it, the speed dropped down into the same low/fluctuating range as before.

Thanks for the suggestion, I'll definitely try this. Will the pool function as normal for the purposes of testing with one of its drives removed yes?

Apologies, I forgot to attach the server-diagnostics.zip file in the opening post....here it is now.... server-diagnostics-20221016-1307.zip

Thanks for the reply Jorge, No the cache pool isn't old - the 870 EVO was bought this year and has ~500 hours logged (total lbas written = 1152436200), and the 860 EVO was bought maybe 2 years ago and has ~6000 hours on it (total lbas written = 22846605052). Neither have any reallocated sectors, and appear in perfect health. Both drives also report as 1MiB alligned. Trimming is scheduled for a daily run @ 16:30, using Unraid's own Trim tool (settings, scheduler, trim).

Hi all, Wondering if anyone can advise me. I've had a long enough standing issue, persistent through multiple Unraid releases, thereby I can't saturate write speeds to my cache drive. 95% of the time, anything I transfer across the LAN here will fluctuate between 50-70MB/s when transferring from my PC (Windows 10) to my Unraid Server (using x2 SSD cache drives in a BTRFS pool.) If I bypass the SSD Cache Pool, and transfer directly to the array, I'll saturate the LAN speed (~112MB/s), which rules out any type of hardware/network issue. So it's actually slower for me to use my SSD write cache, which is frustrating. The Cache pool is made up of a Samsung 870 EVO 1TB, and a Samsung 860 EVO 1TB, so not exactly bargain bin drives. I've read a fair bit on this issue, it's not uncommon, but seemingly quite individual at times. The most recent thing I tried was adding... server min protocol = SMB3_11 client min protocol = SMB3_11 ...to my Samba Extra Configuration settings in Unraid, but to no avail. When I originally set up Unraid, I think one of the 6.7 or 6.8 releases, I had no such issues with transfer speeds, and could saturate the write cache without problem. I'm at my wits end now and unsure how to diagnose the issue. This happens for large single files, and not only for large amounts of small files where you'd expect to see this behavior. Speeds are erratic, and hugely inconsistent. The very odd day though, it might not happen and I'll see ~114MB/s across the lan to the write cache, but it never lasts, and the next day I'll be right back to fluctuating/slower speeds.

Wondering can anyone help/advise me here, I'm having a very intermittent problem with a "Docker Image Disk Utilization of 100%" error popping up for me. I'm on Unraid 6.11.1 (though this has happened to me on previous release versions too), and running the latest Emby as of writing (4.7.8.0, though again, previous releases threw this error up too.) Last night I got an alert about this error, and then ~5 mins later another alert to state the utilization had returned to normal levels, so I wasn't able to check anything really. I feel it's a transcoding issue, and something screwed up with my directory config perhaps? My cache pool is x2 1TB SSD's in a BTRFS pool. I do share parts of my Emby library with select family members, and looking at Emby when the error popped up last night, there was indeed a family member logged in a consuming media. My setup is as follows: Folder on cache pool for Emby transcoding is - "/mnt/cache/appdata/EmbyServer/transcode/transcoding-temp" My Emby server is then configured to use the container path of "/Transcoding" which is pointed to the host path of "/mnt/cache/appdata/EmbyServer/transcode" If I then play media on my LAN and select a low quality version, I can see the "/mnt/cache/appdata/EmbyServer/transcode/transcoding-temp" starts to become populated with files/folders....so I THINK Emby is correctly transcoding onto my SSD pool, and NOT within the docker image itself? Can anyone help/advise?

Sorted there on Windows 10, I changed the attached setting to display as shown. It was set to "Use NTLMv2 Security Session if needed", and I vaguely remember changing this setting ages ago to help with slow SMB speeds, so maybe that's the issue? Unfortunately though, I'm still seeing fluctuating/slow smb transfers to my cache drive (980 Evo x2 in BTRFS)

Same thing happened to me there, updating from 6.10.3 to 6.11 - no smb access to any of my exported shares, credential errors. I reverted back to 6.10.3 and all is good again.

Using cronguru, it seemed to me that "30 20 1 * *" appears to translate to the 1st of every month, whereas "30 20 * * *" translates to a trigger of half past eight pm every single day - or have I misunderstood?

@saarg many thanks for your help. I've edited and uploaded the file to the server now. I've changed the cron expression to "30 20 1 * *" which I believe is the first of every month. Hopefully that'll sort things not autorenewing

Cheers, I've got this far with Unraid but cron is something I've no experience of (other than a predefined user script to shut the server down for me at night.) Is the file to control this a global file, or specific to each docker? I'm comfortable editing, & using a cron calculator to figure out what time I'd like, I just don't know what to actually edit! Would appreciate any help you might throw my way EDIT: I'm looking at the file located at /mnt/cache/appdata/swag/crontabs/root Using Notepad++, I can open this file on Windows and it shows: # do daily/weekly/monthly maintenance # min hour day month weekday command */15 * * * * run-parts /etc/periodic/15min 0 * * * * run-parts /etc/periodic/hourly 0 2 * * * run-parts /etc/periodic/daily 0 3 * * 6 run-parts /etc/periodic/weekly 0 5 1 * * run-parts /etc/periodic/monthly # renew letsencrypt certs 8 2 * * * /app/le-renew.sh >> /config/log/letsencrypt/letsencrypt.log 2>&1 Is it case of editing one of these values, to change renewal time from the default of 2am to a time of my choosing?

Hi all, Basic setup is Unraid 6.9.2 with the Swag docker installed and running away perfectly (I use it for a reverse proxy for my family to use Unraid, having followed SpaceInvaderOne's guide to set up.) The docker itself works perfectly, My family and I can access my Emby library from on and off the lan (duckdns used also.) However, I received an email recently from [email protected], stating my Swag certificates were expiring soon. My server turns off every evening at midnight, and starts back up every day at 16:00, so having googled this problem, most advice was that simply restarting the Swag docker would renew the certs (obviously this isn't happening for me, as my whole server restarts daily.) I found some info which allowed me to renew my certificates manually, by using the following instructions: Open console for the specific docker (Swag) by clicking the docker name, and then choosing the console. Type: certbot renew ^^ This seems to have resolved the issue of the cert not renewing automatically. However I'm concerned that I'll have to do this every few months & maybe forget altogether. So my question is this, how on earth can I automate the renewal myself? I can access the terminal through the Unraid GUI, but after that I'm lost. I'm comfortable typing in commands, but automating this process is a step beyond my knowledge. I have the User Scripts plugin installed, and I use this to shutdown my system every night. As for how I'd use this plugin though to automate cert renewal, I'm not sure. I think I'd have to write a script, and then point to that script in the plugin & then set the schedule? Can anyone help? EDIT: This is from my Swag docker log [cont-init.d] 60-renew: executing... The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am). [cont-init.d] 60-renew: exited 0. So perhaps the docker is set to renew automatically at 02:08 - and therein lies the problem because my Server is offline at that time?

Thanks, I'll check that now

Hi all, Basic setup is Unraid 6.9.2 with the Swag docker installed and running away perfectly (I use it for a reverse proxy for my family to use Unraid, having followed SpaceInvaderOne's guide to set up.) The docker itself works perfectly, My family and I can access my Emby library from on and off the lan (duckdns used also.) However, I received an email recently from [email protected], stating my Swag certificates were expiring soon. My server turns off every evening at midnight, and starts back up every day at 16:00, so having googled this problem, most advice was that simply restarting the Swag docker would renew the certs (obviously this isn't happening for me, as my whole server restarts daily.) I found some info which allowed me to renew my certificates manually, by using the following instructions: Open console for the specific docker (Swag) by clicking the docker name, and then choosing the console. Type: certbot renew ^^ This seems to have resolved the issue of the cert not renewing automatically. However I'm concerned that I'll have to do this every few months & maybe forget altogether. So my question is this, how on earth can I automate the renewal myself? I can access the terminal through the Unraid GUI, but after that I'm lost. I'm comfortable typing in commands, but automating this process is a step beyond my knowledge. I have the User Scripts plugin installed, and I use this to shutdown my system every night. As for how I'd use this plugin though to automate cert renewal, I'm not sure. I think I'd have to write a script, and then point to that script in the plugin & then set the schedule? Can anyone help? EDIT: This is from my Swag docker log [cont-init.d] 60-renew: executing... The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am). [cont-init.d] 60-renew: exited 0. So perhaps the docker is set to renew automatically at 02:08 - and therein lies the problem because my Server is offline at that time?

Thanks for the reply jonathanm. That makes a lot of sense, because it seems that Windows is connecting to the Server on boot for no apparent reason. So I was all set to test your theory out there this morning....and wanted to just ensure the problem was still present before I started. It wasn't. I'd normal access to my shares for some reason, the problem was gone. I racked my brains trying to figure out what the hell had changed that could have fixed the problem. Then the light in my head went on. Yesterday evening, I had used the "clear file explorer history" feature in Windows Explorer as the left hand pane of my explorer had gotten cluttered up. Within the history prior to clearing it, must have been my public share? I'm wondering now with that list cleared, is Windows behaving by not trying to connect on boot to any paths in that list?

Hi folks, I (like many in the past) am having issues with Unraid SMB shares on a Windows 10 client machine. The basic setup of my Unraid shares is they are ALL Secure, with the exception of a single Private share, and a single Public share. The issues I'm having only began after I re-installed Windows on my client machine, & before that, everything worked as it should. The issue is basically when I clean boot Windows (and indeed a clean boot of the Unraid Server itself)....I can't gain access to ANY of my shares. I'll get the dreaded "Multiple connections to a server or shared resource by the same user, using more than one username, are not allowed" error that I've seen mentioned on the forums many times. It's confusing because these are CLEAN boots we're talking about here, there are no other connections happening. I've confirmed this by running "net use * /delete" in the command prompt, which results in "There are no entries in the list", confirming that nothing else from the client machine is accessing Unraid. I originally had an Unraid user defined, e.g. john with a password of say 1234. Along with other Unraid users too...who had no issue accessing their defined shares with their assigned passwords. Once I reformatted the OS drive on the client PC though, and reinstalled Windows, that all went down the toilet. I wasn't able to access ANY share, despite using the credentials defined for a given Unraid user. So I read that if I change the Unraid user to match that of my Windows sign it, this resolves the issue....which it didn't. I've an MS account which is tied to my Windows, so had no username as such. It's based on an email address. So I tried setting up an Unraid user, e.g. johndoe (if MS accoutn was [email protected] for example), and matched the password with the Windows pin sign-in, e.g. 12345678. Same result, no access to shares. I've checked the credential manager, and there's nothing there saved that's relevant to Unraid. There's a few entries set up, MS account, OneDrive, XboxLive, and some others MS has setup as default....but nothing there that is relevant to Unraid. The 'solution' to the problem, has been to manually create an entry in the Credential Manager...the details of which are the name of the Unraid Server itself, then the username is Tower\john, and password put in. This gives me instant access to all the shares that 'john' has been given access too. So it's sort of solved, but not quite. If anyone else were to use this Windows session, they have no way to input their own credentials to access their own shares (I could set up multiple Windows profiles I suppose, but it'd be great if I didn't have to)...and secondly, more importantly, 'john' has instant access to those shares without having to use ANY credentials (given their now stored in the credential manager)...I'm quite concerned about malware like Ransomware having instant access to those shares any potentially encrypting any relevant content on said shares. Is there no way I can just be prompted with a user/password box, and for it to just work like it did before? I've had a good read of this thread -

Just piggybacking onto this, I've only recently come across this little annoyance. I'm currently based in Dublin, Ireland....which is UTC+1. However, within Unraid's own time & date settings, Dublin is listed as UTC+0. Unraid seems to pull the correct time when in operation, and displays the correct time & date despite the lack of a +1 to account for the timezone. However, on shutdown, as discussed in this thread, it is setting my bios time back by one hour. It's as if the time set on shutdown DOES NOT account for the timezone I'm in. If within Unraid I was able to set Dublin as UTC+1 (as that is the correct offset), then the shutdown time pushed to the bios should also be UTC+1, and there'd be no issue. As is stands, it seems for me that Unraid is incorrectly pushing UTC+0 to the bios, instead of UTC+1 given that timezone I've set within the settings. Unraid Settings: World Clock: