Tolete

Glad it was helpful.

this be great, anyone got a guide on installation yet?

your welcome.

after update, can't get to web-gui?

Thank you.

Anyone 'cloudflared-tunnel' randomly stop/crashed (not sure which). I have noticed it couple times now, container has stopped/crashed on its own. start the container starts without any problems after the crash/stop. anyone running it with a restart policy '--restart unless-stopped' ?

never that simple, site shows directories are writable? POSSIBLE FIX: changing/correct the ownership and permissions, this did not fix my issue. BUT if you have jacked up your permissions this will get you back to 'stock'. Running, and testing permissions fix did not solve my issues. sudo chown -R nobody:nobody /mnt/user/appdata/wordpress sudo find /mnt/user/appdata/wordpress -type d -exec chmod 755 {} \; sudo find /mnt/user/appdata/wordpress -type f -exec chmod 644 {} \; THE FIX: Adding the following lines to the "wp-config.php" file in the WordPress installation directory: define('FS_METHOD', 'direct'); define('FS_CHMOD_DIR', 0777); define('FS_CHMOD_FILE', 0777); This will force WordPress to use the "direct" method for updating plugins and themes, and set the directory and file permissions to 0777, which allows all users to read, write, and execute the files and directories. After adding code to my wp-config.php and re-testing solved my issue.

WordPress recently wants an FTP access to update plugins and themes, I'm thinking somehow it lost permissions to write to the necessary directories. ls -la /path/to/wordpress any advise on restoring permission to default? i'm thinking something like; sudo chown -R nobody:nobody /mnt/user/appdata/wordpress sudo find /mnt/user/appdata/wordpress -type d -exec chmod 755 {} \; sudo find /mnt/user/appdata/wordpress -type f -exec chmod 644 {} \; send help @Kru-x

These error messages indicate that there is a problem with the Nextcloud installation on your server. Specifically, there is a naming conflict with the Redis class in the Memcache module. The error message "Cannot declare class OC\Memcache\Redis, because the name is already in use" suggests that the Redis class has already been declared, and attempting to declare it again is causing a fatal error. I would check your Nextcloud config file for code related to Redis/Memcache | Nextcloud documentation on Memcache. your config should look something like this.

yup, its missing on Cloudflare side. add it to cloudflare and re-scan

It's possible that your ASUS PCIe breakout board is not allowing Samsung Magician to detect your NVMe SSDs, especially if the board does not have its own NVMe controller or if the controller is not compatible with Samsung Magician. To troubleshoot the issue, you can try the following steps: Check if your NVMe SSDs are detected by the system BIOS. If they are not detected, then the issue may be with the PCIe breakout board or the NVMe SSDs themselves. Check if your NVMe SSDs are compatible with Samsung Magician by visiting the Samsung website and checking the list of compatible drives. If your SSDs are not listed, then they may not be eligible for firmware updates with Samsung Magician. Try connecting the NVMe SSDs directly to the motherboard instead of using the PCIe breakout board. If they are detected, then the issue is likely with the PCIe breakout board. If none of the above steps work, you may need to contact ASUS support or Samsung support for further assistance. I would also triple check and make sure that the firmware selection you are making for your drive is correct.

The 'upgrade-insecure-requests' header instructs the browser to automatically upgrade HTTP requests to HTTPS. This is a useful security measure to protect against man-in-the-middle (MITM) attacks and mixed content vulnerabilities. However, using this header alone is not enough to provide full Content Security Policy protection for your website. Content Security Policy (CSP) is a security standard designed to mitigate the risk of cross-site scripting (XSS), clickjacking, and other code injection attacks. It is recommended to use a properly configured CSP in addition to the 'upgrade-insecure-requests' header to provide a more comprehensive security posture for your website. Regarding the 'interest-cohort=()' directive, it is a new feature introduced by Google to combat online tracking by preventing websites from accessing a user's unique identifier or "cohort" information. The cohort information is used by Google to group similar users together for interest-based advertising. By adding 'interest-cohort=()' to your CSP, you are telling the browser to disallow the use of this feature, which could help protect user privacy. However, this directive is not yet widely supported by all browsers, and its impact on website functionality is still being studied. In .htaccess file: # Content Security Policy (CSP) Header always set Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; connect-src 'self'; font-src 'self'; img-src 'self'; manifest-src 'self'; script-src 'self'; style-src 'self';" In default.conf file: # Content Security Policy (CSP) add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; connect-src 'self'; font-src 'self'; img-src 'self'; manifest-src 'self'; script-src 'self'; style-src 'self';" always; in cloudflare, modify the values for 'Content-Security-Policy' with: default-src 'none'; frame-ancestors 'none'; connect-src 'self'; font-src 'self'; img-src 'self'; manifest-src 'self'; script-src 'self'; style-src 'self'; It is possible that this can break some of your subdomains ,those subdomain websites are using external resources (such as scripts, stylesheets, or images) that are not hosted on your domain. In this case, you may need to add additional directives to your CSP to allow those external resources. To debug this issue, you can use the browser console to see which resources are being blocked by the CSP, and adjust the CSP directives accordingly. You can also use a CSP reporting tool (such as the one provided by Google) to get more detailed reports on CSP violations. In general, it is important to be careful when implementing CSP, as it can have unintended consequences if not done properly. It is recommended to start with a more permissive policy (such as "default-src 'self'") and gradually tighten it as needed, while monitoring for any issues. i would recommend just going with "upgrade-insecure-requests" to keep it from breaking other sites/apps you maybe running.

no problem, i'm also seeing in the logs after after changing the admin token from plain text to an Argon2 PHC string, [vaultwarden::api::admin::_][WARN] Request guard `AdminToken` failed: "Unauthorized".

password iterations- Whether using the Bitwarden defaults is better or not depends on your individual security needs and preferences. Bitwarden's default settings are designed to provide a good balance between security and usability for most users. However, some users may have higher security requirements or preferences, and may choose to adjust the settings accordingly. Increasing the password iteration from 100,000 to 350,000 will indeed make it harder for attackers to crack your password, as it will take them longer to test each potential password. However, this also means that it will take longer for you to log in to your vault, especially on devices with slower processors. Ultimately, it is up to you to decide which settings work best for you. You should consider your individual security needs and preferences, as well as the performance of your devices when making these decisions. If you find that the increased password iteration is causing significant delays in accessing your vault from your phone, you may want to consider reducing it to a level that provides a good balance between security and usability. as for the 'OWASP minimum recommended settings'- this changes your 'ADMIN_TOKEN' from a plain text token (insecure) to a PHC string (secure).

im thinking something like this might work. Create a rights file with the following contents: [addressbook1] user: user1 collection: addressbook1 permissions: RW [addressbook1] user: user2 collection: addressbook1 permissions: R This will give user1 read and write access to addressbook1, and user2 read-only access to addressbook1. Edit your Radicale configuration file and make sure it includes the following: [server] ... [auth] type = htpasswd htpasswd_filename = /path/to/htpasswd/file ... [rights] type = authenticated file = /path/to/rights/file ... [collections] enabled = addressbook ... this would allow user1 to read/write access, while user2 would only have read access to the same addressbook1

hello, - add config/user files to /config directory. -delete admin user from user file and hash your own. -access the webGUI, uploaded addressbook file (vcard file). -after upload, edit addressbook and renamed to 'addressbook1'. -Up and running no problem. Thank you. I'm looking to make 'addressbook1' read-only, send help

log showing [NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure. Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`. See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token THE FIX ⚠️This feature is released in 1.28.0+. Previous versions do not support Argon2 hashing. # Using the OWASP minimum recommended settings Open command prompt and run docker exec -it vaultwarden /vaultwarden hash --preset owasp This will generate a PHC string Generate an Argon2id PHC string using the 'owasp' preset: Password:MYSECRETEPASSWORD Confirm Password:MYSECRETEPASSWORD ADMIN_TOKEN='copy everything inside ' ' only, this is the new generated PHC string' MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store. MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store. MYSECRETEPASSWORD - is what you will use to access the admin page, so keep it safe/store. NOTE/SAVE/STORE/COPY - the output of the new generated PHC string ADMIN_TOKEN. everything inside ' ' only. Edit your vaultwarden docker container, and paste in the new PHC generated ADMIN_TOKEN string. Save/Restart container. Navigate to your vaultwarden admin panel, enter your existing (old) plain text ADMIN_TOKEN. Go to, Settings > General settings > Admin page token: paste in your generated ADMIN_TOKEN string (everything inside ' ' only). Save, admin panel. restart container. check logs, notice the [NOTICE] warning no longer present. done. See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token for other options.

Adding security headers using transform rules in Cloudflare should not cause any direct problems for other sites hosted through the same domain. However, it is important to keep in mind that the security headers will be applied to all traffic to the domain, including traffic to subdomains. This means that if any subdomains have different security policies or settings, those services may be impacted by the new security headers. I haven't seen any, but do note, the Content Security Policy (CSP) and Permissions Policy headers protect your site or in this case sites against a variety of attacks, such as cross-site scripting (XSS), code injection, clickjacking, and unauthorized access to sensitive features and APIs. CSP allows you to specify which sources of content are trusted, while Permissions Policy allows you to control which features and APIs are available to your site. By using these headers, you can improve the security of your site and reduce the risk of data breaches and other security incidents. you can always add/monitor/test.

I did. The default might break something and all you need optional security headers. I would just update, add to CF, restart and rescan, you should be golden. lmk

FYI, this is not related, to any NC version updates, this is just for 'server hardening' these are extra security 'headers' you can add. The scan points out where you can improve. So just add this missing two security headers for the A+ double check/add to your default.conf file # HTTP response headers borrowed from Nextcloud `.htaccess` add_header Referrer-Policy "no-referrer" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Download-Options "noopen" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Permitted-Cross-Domain-Policies "none" always; add_header X-Robots-Tag "noindex, nofollow" always; add_header X-XSS-Protection "1; mode=block" always; Save. double check/add to your .htaccess file <IfModule mod_env.c> # Add security and privacy related headers # Avoid doubled headers by unsetting headers in "onsuccess" table, # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002 Header onsuccess unset Referrer-Policy Header always set Referrer-Policy "no-referrer" Header onsuccess unset X-Content-Type-Options Header always set X-Content-Type-Options "nosniff" Header onsuccess unset X-Frame-Options Header always set X-Frame-Options "SAMEORIGIN" Header onsuccess unset X-Permitted-Cross-Domain-Policies Header always set X-Permitted-Cross-Domain-Policies "none" Header onsuccess unset X-Robots-Tag Header always set X-Robots-Tag "noindex, nofollow" Header onsuccess unset X-XSS-Protection Header always set X-XSS-Protection "1; mode=block" SetEnv modHeadersAvailable true </IfModule> Save. i use Cloudflare, so you will need to add it on there also. so Cloudflare > YOURDOMAIN > Rules > Transform Rules > Modify Response Header Save. restart container, then rescan.

post your # HTTP response headers borrowed from Nextcloud `.htaccess` section from your default.conf file.

not NC version related, you are just missing it.

https://securityheaders.com/

please post your # HTTP response headers borrowed from Nextcloud `.htaccess` section from your default.conf file. currently sitting on A+ here, no errors 👨‍💻

after upgrading to NC 26.0.0 Administration settings > Overview error- The "X-Robots-Tag" HTTP header is not set to "noindex, nofollow". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly. The Fix: update [line 54] on your default.conf file appdata > nextcloud > nginx > site-confs > default.conf from add_header X-Robots-Tag "none" always; to add_header X-Robots-Tag "noindex, nofollow" always; Restart container.