Jump to content

aleary

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

2 Neutral

About aleary

  • Rank
    Member

Converted

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @DingHo, I recall from having problems adding external SMB/CIFS shares a while back, that the "Domain" field is, or was, required. From your screenshot you don't appear to have anything set there. If you don't have an actual domain, use the Workgroup name used by windows on your network. Defaults to "WORKGROUP". /Alan.
  2. There has been an issue raised re the Android Auto-upload problem. See the following: https://github.com/nextcloud/android/issues/2249 It seems the problem is with the creation of the new monthly directory by the Auto-upload process. i.e. /InstantUpload/Camera/2018/03 When the directory doesn't exist in the Nextcloud server, the upload fails. Until a fix is released you can resolve it manually by creating the missing directory and ensuring that you sync the directory to your phone before retrying the upload. The following worked for me: Browse in the Android app, to /InstantUpload/Camera/2018/ Create the "03" directory that was missing. Refresh the directory to ensure everything is synced Go to the Uploads section Select the "Retry failed uploads". All the outstanding uploads then uploaded without error.
  3. I've had the same problem with the Android app for the last few days. The Auto-Upload of images taken with the camera gives the "Server unavailable" message, however images from other apps, e.g. WhatsApp, are uploading fine. Everything else about the Android app seems fine, can browse, download files, etc. without any problems. The logs don't show any errors at all. The successful uploads show something like the following in the access.log: 172.17.0.1 - aleary [01/Mar/2018:14:12:02 +0000] "GET /index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:02 +0000] "GET /index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:09 +0000] "HEAD /remote.php/webdav/InstantUpload/WhatsApp%20Images/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:09 +0000] "GET /index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:13 +0000] "PUT /remote.php/webdav/InstantUpload/WhatsApp%20Images/IMG-20180301-WA0000.jpg HTTP/1.1" 201 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:14 +0000] "PROPFIND /remote.php/webdav/InstantUpload/WhatsApp%20Images/IMG-20180301-WA0000.jpg HTTP/1.1" 207 867 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:15 +0000] "HEAD /remote.php/webdav/InstantUpload/WhatsApp%20Images/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:15 +0000] "GET /index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" 172.17.0.1 - aleary [01/Mar/2018:14:12:15 +0000] "GET /index.php/apps/files/api/v1/thumbnail/256/256/InstantUpload/WhatsApp%20Images/IMG-20180301-WA0000.jpg HTTP/1.1" 200 14287 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" But the failed ones only log a single line: 172.17.0.1 - aleary [02/Mar/2018:15:06:14 +0000] "GET /index.php/204 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.0.2" Might be a problem in the Android app itself, then doesn't attempt to actually upload.
  4. I had the same problem with running the preview generation. PHP is configured with a memory limit of 128MB. I tried bumping this up to 256MB and it's working fine for me now. To change the PHP config, open a shell into the Nextcloud docker and edit the PHP config file docker exec -it nextcloud bash nano /etc/php7/php.ini You're looking for the following section, where you can increase the memory limit. ; Maximum amount of memory a script may consume (128MB) ; http://php.net/memory-limit memory_limit = 128M Then restart the Nextcloud docker to pick up the configuration change.
  5. I highly recommend that guide by @CHBMB. No need to go near Apache. The LetsEncrypt docker uses Nginx, which is also a web server. It works well for this and I believe is less resource hungry than Apache. DNSMasq is a light weight DNS & DHCP server and is actually used in many routers. Yours may be using it already. Other DNS services should be able to easily configure the same. Basically, I have a static IP address assigned to my Unraid server "unraid.localdomain", but have additional alternative names configured too, i.e. "nextcloud.mydomain.com", so the router resolves requests for both names to the same local static IP address, e.g. 192.168.x.x.
  6. I had a domain name already, so I haven't tried it with a DDNS domain name. From doing a quick search, it seems that it is possible to use LetsEncrypt with sub-domains from DDNS services. It looks like there were problems in the past with limits on the number of certificates issued per domain, but as long as the domain used is on the public suffix list (https://publicsuffix.org), that shouldn't be a problem. Some of the guys on the LetsEncrypt docker forum may be able to provide more info on that type of setup.
  7. I'm not quite sure how to fix your specific setup, i.e. using AirVPN, etc., but I've got mine set up so I can use the same URL whether internally, externally or over VPN. Basically, I'm using the LetsEncrypt docker to provide SSL and Reverse-Proxy for Nextcloud and other dockers. My router is then configured to forward port 443 from outside to the LetsEncrypt docker, which in turn proxies connections to the NextCloud docker. Internally, I'm using DNSMasq for DNS and to override the external hostname with the IP address of the LetsEncrypt docker. In all cases I'm connecting to the URL https://nextcloud.mydomain.com:443/ which connects to the LetsEncrypt docker. I don't connect to NextCloud directly. So, from outside I connect to https://nextcloud.mydomain.com:443/ which the router forwards to the LetsEncrypt docker at https://192.168.x.x:443/. This then proxies on to the NextCloud instance at https://192.168.x.x:943/ On my local network, DNSMasq is configured to resolve "nextcloud.mydomain.com" to "192.168.x.x", which means that I can use the same hostname to connect to the LetsEncrypt proxy internally. When connected over VPN, I have DNS configured to resolve over the VPN connection, so this works as if I were on the internal network, again using DNSMasq to provide the internal IP address for "nextcloud.mydomain.com". Hope that might give you some ideas. /Alan.
  8. I had similar client timeout issues after changing my letsencrypt/nextcloud settings. (I was changing from www.mydomain.com/nextcloud to nextcloud.mydomain.com) It turned out that the Android and Windows clients repeatedly attempted to connect using the old URL before I managed to change their settings to the new URL. The BruteForce Login Protection in Nextcloud kicked in and slowed/prevented all my client apps from connecting. You may have run into the effects of this feature too. Check the admin log for entries like the following: Bruteforce attempt from "172.17.0.1" detected for action ... Also check the "oc_bruteforce_attempts" table in your database. Clearing out the relevant entries in this table resolved the problem for me. /Alan.
  9. Hi guys, I had still been having problems with protected SMB/CIFS shares on releases after 60, but I've found a solution. I don't have an actual windows domain on my home network so, like most, my Unraid host and Windows clients are using the default workgroup called "WORKGROUP". When originally adding my shares I had left the "Domain" field empty and authentication for shares on my Unraid host worked fine with just username and password configured. @CHBMB I noticed in your screenshot that you had the domain set as "WORKGROUP", so having added that to each of mine they now work perfectly. Looks like something changed in the handling of the "Domain" field from release 61 onwards, with an empty domain no longer being treated like a workgroup. /Alan.
  10. Hi guys, I'm seeing the same problem with SMB shares with the latest version of NextCloud. Reverting back to build 60 has fixed it for the time being. Along with that, I've had the NextCloud client on windows locally removing all the content of one of those shares, before I shut it down, as it seems to consider them deleted, rather than just unavailable. Regards, Alan.
  11. Thanks for the pointer, johnnie.black. I ran xfs_repair, as guided, and following some repairs made, all appears to be fine. I'm still not sure why this occurred to start with, but will be keeping a close eye on things. Thanks again, Alan.
  12. My system has just generated a number of disk errors, and I'm wondering what the cause would be and what I should do to fix it. System: Unraid 6.3.2 16GB ECC RAM Array : 3 x 4TB array drives, (1 parity and 2 data drives (xfs)) Cache Pool: 2 x 256GB SSD drives (btrfs). I was logged into Unraid via SSH converting a VMWare vmdk disk image to use with Unraid using "qemu-img", writing about 30GB to a share that does not have caching enabled, so writing directly to the array when this error was returned: qemu-img: error while writing sector 9302014: Input/output error Checking the syslog I found the following: Feb 28 15:49:49 unraid kernel: XFS (md1): Internal error XFS_WANT_CORRUPTED_GOTO at line 3504 of file fs/xfs/libxfs/xfs_btree.c. Caller xfs_alloc_fixup_trees+0x184/0x2c2 ... Feb 28 15:49:49 unraid kernel: XFS (md1): Internal error xfs_trans_cancel at line 983 of file fs/xfs/xfs_trans.c. Caller xfs_iomap_write_allocate+0x29c/0x2ca ... Feb 28 15:49:49 unraid kernel: XFS (md1): xfs_do_force_shutdown(0x8) called from line 984 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff812b1cef Feb 28 15:49:50 unraid kernel: XFS (md1): Corruption of in-memory data detected. Shutting down filesystem Feb 28 15:49:50 unraid kernel: XFS (md1): Please umount the filesystem and rectify the problem(s) Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748705, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748706, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748707, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748708, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748709, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748710, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748711, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748712, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748713, lost async page write Feb 28 15:49:50 unraid kernel: Buffer I/O error on dev md1, logical block 547748714, lost async page write Feb 28 15:49:50 unraid shfs/user: err: shfs_write: write: (5) Input/output error The Unraid UI doesn't show any issues other than the syslog, and there don't appear to be any SMART disk errors. However, any access on the md1 drive from the CLI fail with "Input/output error". Does the "Corruption of in-memory data detected" indicate a potential RAM issue, rather than a disk issue? Perhaps I should run memtest on the system to check that. Diagnostics are attached. Any suggestions would be gratefully received. Kind regards, Alan Leary. unraid-diagnostics-20170228-1609.zip