You are not logged in.
Have set a LAMP as per arch wiki without any major issue. Put nextcloud in /srv/http/ and can acces it via 192.168.x.x/nextcloud (on my local network).
Is there a way to get it to work by simply using ip address, currently directory listing shows (which I tried to stop by adding line given in wiki [[http.conf]])?
Nextcloud complains about .htaccess not setup correctly?
Think SSL is covers in wiki guide so should be able to add that.
Last edited by Mr Green (2016-10-02 07:19:48)
Mr Green I like Landuke!
Offline
Hi,
1) Yes there is. But it's rather hard to help you without your existing configuration file. Pease post it.
(But it should be as simple to put your 'DocumentRoot /nextcloud/path' directly in the VirtualHost section of your ip address)
2) What is the exact message?
Offline
The .htaccess file is not working. We strongly suggest that you configure your web server in a way that the data directory is no longer accessible or you move the data directory outside the web server document root.
I am going to move root folder at some point.
Mr Green I like Landuke!
Offline
Please double check that you have the "AccessFileName .htaccess" line in your config and also that the .htaccess file exists in the DocumentRoot of nextcloud and is readable by the apache process. Also a "AllowOverride None" option in a Directory context will disable the .htaccess file in that folder.
If that doesn't fix your problem you really need to post your config files.
(I assume you mean by LAMP that you really use Apache as webserver)
Offline
Sorry yes Apache as server, fixed document root to point to nextcloud directory.
.htaccess is present in nextcloud and permissions are http:http... Will check your suggestions
Thanks for your help
Mr Green I like Landuke!
Offline
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other
# <Directory> blocks below.
#
<Directory />
AllowOverride none
Require all denied
</Directory>
In httpd.conf
Mr Green I like Landuke!
Offline
.htaccess is a very old approach and only really needed now when you don't have access to the server configs (e.g. running in a shared hosting environment).
But in any case this is all much simpler. Just add a /srv/http/index.php file with the following:
<?php header('Location: 192.168.x.x/nextcloud'); ?>
Another approach would be if you can just include/require the nextclound index file, but I'm not at all familiar with nextcloud and this may or may not work. The header redirect is much more robust.
As a third option, you could just move evertything in the nextcloud directory up to /srv/http. This would likely require some further adjustments though (again, I'm not at all familiar with nextcloud). With any luck nextcloud just defines a single variable for the nextcloud root which is *currently* /srv/http/nextcloud and you'd just change that variable settting to be /srv/http after you moved everything. Most CMSs even have some fancy web-interface for specifying this variable.
As yet another approach (probably the best, this was added as an edit) change the document root in your apache conf from /srv/http to /srv/http/nextcloud.
The file listing that you see with just the IP address is just apaches default behavior when no document is specified and no index.{html,php} is found in the specified directory.
Last edited by Trilby (2016-10-01 13:24:40)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I have tried to remove .htaccess but error still occurs
Your data directory and your files are probably accessible from the Internet. The .htaccess file is not working. We strongly suggest that you configure your web server in a way that the data directory is no longer accessible or you move the data directory outside the web server document root.
Will move data directory to a larger drive in the near future, setting up before I commit to using it.
Off to test php line.....
Mr Green I like Landuke!
Offline
Oops, sorry, I seem to have missed part of the question. But it sounds like you know how to resolve that. If your data is somewhere under /srv/http/nextcloud that is the problem, the data should be elsewhere. There really is no right place for it, though often a CMS will have it's own preference. In my own servers I often create a /srv/secure directory for things that should not be publically accessible but are used by web services - and /srv/secure is *not* anywhere in my apache conf and only in the php open_basedir so php scripts can get data from there as needed.
Big caveate however, I don't know what "data" nextcloud needs/stores, so the nextcloud people might have suggestions on where to put the data.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Will mark thread as SOLVED and seek help from nextcloud as regards to best practise. Have a plan to move nextcloud to a data drive in the near future (to give it the much more room for storage files). The whole point of setting up nextcloud was a local cloud rather than on the net, not exactly sure how someone outside of my network could access it. My thinking is the whole SSL/HTTPS is more for a web based server.
Mr Green I like Landuke!
Offline
Have you somehow opened port 80 on that machine only to the local network? If not, then this is "on the net".
Unless you've specifically blocked external traffic (which is possible) then once you start apache anyone outside your network can access your web content.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Have a feeling port 80 is open (standard setup). Guess I have a lot to learn
[mrgreen@arch ~]$ sudo nmap -sT -O 192.168.x.x
Starting Nmap 7.30 ( https://nmap.org ) at 2016-10-02 13:11 BST
Nmap scan report for 192.168.x.x
Host is up (0.0059s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
8080/tcp open http-proxy
MAC Address: 74:DA:38:2E:08:79 (Edimax Technology)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.68 seconds
[mrgreen@arch ~]$
Last edited by Mr Green (2016-10-02 12:04:02)
Mr Green I like Landuke!
Offline
If you are connecting to that computer via a web browser with the url you indicated, then yes, port 80 *must* be open. If you can see that, so can anyone else *unless* you've specifically blocked external traffic at your router (e.g. the "top" of your local network). There is a bit of "security through obscurity" as your ip address (i.e. the url of your system) isn't really advertised anywhere to draw traffic, but there are more than enough programs out there constantly running and constantly scanning for any IP addresses with port 80 open. They *will* try to connect and *will* gather whatever information they can.
So unless you have a firewall or other block on your router, consider anything you put in your apache document root as accessible by anyone anywhere: it's effectively "posted to the net".
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I will change port and look into making it secure. Was under the impression you had to have a port forwarded in router to allow any kind of link to local pc/server?
Mr Green I like Landuke!
Offline
Changing the port doesn't help much - it adds a little more obscurity, but security through obscurity isn't really secure.
With some routers your impression is correct - but it does depend entirely on your router. So either learn about your router, or assume it is open.
That said, security for the sake of security is silly. Is there anything served that would be dangerous if shared? It may not be your goal to share your files publicly, but would there be harm in someone else seeing them? If not, don't worry about it. If so, then start learning about your router, and add some login/credential check to the server.
HTTPS will not help with this - this encrypts the data in transmission, it does nothing to keep unwanted eyes from seeing data that is served - unlesss of course it is *also* paired with a login system, but the login is what secures the data, https just keeps the credentials secure in transit so someone can't "hijack" them.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Ok so if I wanted to get serious could I set up a access point off my main network and connect that way? It would not even be on my home network at all. Only then someone coming across it would be able to try to access it. Nextcloud does allow files to be encrypted again another layer of security?
Mr Green I like Landuke!
Offline
Ok so if I wanted to get serious could I set up a access point off my main network and connect that way?
I'm not sure I understand exactly what you mean here, but I don't think it matters. If you can type in an IP address into a web browser on computer A and get access to files on computer B without some sort of log in credentials, than so can anyone else unless there is a firewall preventing it.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I was talking ad-hoc, but I understand. Nextcloud does require login so its not open to all. Will look at firewall and adding in more protection.
Thanks for your help
Mr Green I like Landuke!
Offline