There is a mysterious folder being shared in an internal server with Ubuntu 18.04.2 LTS.
There is nothing pointing to that folder in the /etc/samba/smb.conf file. What happen was that this sharing configuration was made before I have access to that server and the person who made it curiously does not remember how did that.
How can I discover how was made that sharing?
# To access your network share
sudo apt-get install smbclient
# List all shares:
smbclient -L //<HOST_IP_OR_NAME>/<folder_name> -U <user>
# connect:
smbclient //<HOST_IP_OR_NAME>/<folder_name> -U <user>
To access your network share use your username (<user_name>) and password through the path` "smb:////" (Linux users) or "\\\" (Windows users). Note that "" value is passed in "[]", in other words, the share name you entered in "/etc/samba/smb.conf".
Note: The default user group of samba is "WORKGROUP".
i hope it might just do.
Might as well put this out there in the event that someone else comes across it. I also had a mysterious samba share that was not listed in the smb.conf.
It turns out I had a symbolic link that was either shared before or pointed to a folder that was shared. Deleting the symlink got rid of the samba share after a smbd service restart. Restoring the symlink from the trash caused the samba share to come back. Very mysterious indeed.
Related
I went to view a postgres schema on my local (MacOS 11) database, and was not able to view my schemas.
Connection Refused in DBeaver!
So I opened my postgres desktop application, and got the warning message, "Stale postmaster.pid file"
How can I fix this?
The problem is that the postmaster.pid file needs to be removed manually and regenerated by postgres, and these are the steps to do it. (Keep in mind the version might change, var-12, might be var-13 etc)
Open your terminal, and cd into the postgres directory: cd /Users/$USER/Library/Application\ Support/Postgres
Make sure you're in the right place, ls you should see something like var-12 or var-<version #>
Verify the file is there, ls var-12 (keep in mind the var-XX is equivalent to your PGSQL version)
Verify the Postgres server is not running by viewing desktop app
Version might change so could be var-12, var-13, etc etc depending on age of this article.
Library/Application Support/Postgres
➜ ls var-12
PG_VERSION pg_hba.conf pg_replslot pg_subtrans postgresql.auto.conf
base pg_ident.conf pg_serial pg_tblspc postgresql.conf
global pg_logical pg_snapshots pg_twophase postgresql.log
pg_commit_ts pg_multixact pg_stat pg_wal postmaster.opts
pg_dynshmem pg_notify pg_stat_tmp pg_xact postmaster.pid <----
Then remove postmaster.pid, rm var-12/postmaster.pid
or rm var-<PG version #>/postmaster.pid
Go back to your console, start your postgres server, and it should be functioning again, and you should have full access to your schemas.
cd /Users/<UserName>/Library/Application\ Support/Postgres/
ls
Then we may view any of the directory names, such as var-9, var-10, var-11, etc... depending on which PostgreSQL version we have installed.
Following that, if we can see var-11,
cd var-11
rm postmaster.pid
In my case I used the code rm var-13/postmaster.pid and solved.
I'm trying to install an SSL certificate on my shared hosting by Plesk.
It worked before, but the renewal went wrong.
I finally uninstalled the certificate, but when I try to get a new one, I can't access the .well-known/acme-challenge folder.
I tried to put a test file inside but ends up with a 404 error.
If I place the file inside .well-known, I can access it.
If I rename the acme-challenge folder to acme2-challenge, I can access it.
What makes this specific acme-challenge file so protected, and where can I unprotect it?
There may be an Apache module or config that controls the directory. Search a config acmetool and the module md in the Apache board or in command line with grep -rinF acme /etc/apache2.
There are two common modules that manages acme, so to fix it, you may run sudo a2disconf acmetool or sudo a2dismod md, then regenerate certificate (you may have to wait one hour or one day if you reach the limit of Let's Encrypt).
To avoid a future issue, search for the package that modified the apache config too.
I got a Mesosphere-EE, and install on fedora 23 server (kernel 4.4)with:
$bash dcos_generate_config.ee.sh --web –v
then output:
Running mesosphere/dcos-genconf docker with BUILD_DIR set to/home/mesos-ee/genconf
Usage of loopback devices is strongly discouraged for production use.Either use `--storage-opt dm.thinpooldev` or use `--storage-opt
dm.no_warn_on_loop_devices=true` to suppress this warning.
07:53:46:: Logger set to DEBUG
07:53:46:: ====> Starting DCOS installer in web mode
07:53:46:: DCOS Installer v1
07:53:46:: Starting server ('0.0.0.0', 9000)
Then I start firefox though vnc, the vnc is on root. then:
07:53:57:: Root page requested. 07:53:57:: Serving/usr/local/lib/python3.4/site-packages/dcos_installer/templates/index.html
07:53:58:: Request for configuration type made.
07:53:58::Configuration file not found, /genconf/config.yaml. Writing new onewith all defaults.
07:53:58:: Error handling request
PermissionError: [Errno 13] Permission denied: '/genconf/config.yaml'
But I already have a genconf/config.yaml, it look like:
bootstrap_url: http://<bootstrap_public_ip>:<your_port>
cluster_name: '<cluster-name>'
exhibitor_storage_backend: zookeeper
exhibitor_zk_hosts: <host1>:2181,<host2>:2181,<host3>:2181
exhibitor_zk_path: /dcos
master_discovery: static
master_list:
- <master-private-ip-1>
- <master-private-ip-2>
- <master-private-ip-3>
superuser_username: <username>
superuser_password_hash: <hashed-password>
resolvers:
- 8.8.8.8
- 8.8.4.4
I do not know what’s going on. If you have any idear, please let me know, thank you very much!
Disable Selinux!
Configure SELINUX=disabled in the /etc/selinux/config file and then reboot!
Be ensure the selinux is disabled by the command getenforce.
$ getenforce
Disabled
zhe.
Correctly installing the enterprise edition depends on the correct system prerequisites. Anyway I suppose you're still on the bootstrap node so I will give you some path to succed in your current task.
Run the script as root or as a user issuing sudo dcos_generate_config.ee.sh
The script will also generate the config file automatically; if you want to use your own configuration file then create a folder named genconf and put it inside before running the script. You should changes the values inside <> with your specific configuration. If you need more help for your specific case send me an email to infofs2 at gmail.com
I have what is almost certainly a newbie question. I expected to find the issue while writing this question, but I am still stuck.
I want to change the DocumentRoot for apache, but I keep getting the error message "DocumentRoot must be a directory".
Situation:
The code is running in a virtual VMWare machine 4.0.4 build-744019
The version of linux is Scientific Linux release 6.4 (Carbon)
The version of apache is Apache/2.2.15 (Unix) (this is a yum install with nothing
special)
In the httpd.conf
DocumentRoot "/home/stave/www"
When I restart, I get the message
Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory
Steps taken so far:
I ensured that the directory exists:
ls -asl /home/stave
4 drwxrwxrwx. 2 stave stave 4096 Feb 9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists
I considered that it might be a priviledges issue so (this is a virtual development machine isolated from the internet, and I am troubleshooting so I am not too worried about security) as you can see I set the priviledges to 777.
I even changed the user that apache is running as (and confirmed that the change worked with ps) to stave to ensure that priviledges just shouldn't be an issue.
Stackoverflow
There are a few stack overflow answers, but most of them say "read the error message. It is saying that the directory doesn't actually exist". Others implied that there might a trailing slash at the end which would be bad.
Other websites
The most useful I found was this that advised
You probably got "DocumentRoot must be a directory" error even it is really a directory because of SELinux extensions. Run system-config-securitylevel (or redhat-config-securitylevel) to disable SELinux for httpd or give SELinux permissions to that
directory:
chcon -R -h -t httpd_sys_content_t /path/to/directory*
My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.
Current situation
I have run out of ideas to try, so any diagnostic questions or advice would be greatly appreciated
The link you posted under "Other websites" highlights the root cause of your problem, which is Selinux.
Unless the server is part of a super secure environment, I would simply disable Selinux.
On RedHat / CentOS / Scientific Linux this can easily be done by editing /etc/sysconfig/selinux - find the parameter "selinux" and change the option "enforcing" to "disabled" as per the extract below:
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
It is probably wise to reboot the server after making this change.
You shouldn't just disable SELinux.
You need to set httpd_enable_homedirs to on.
yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on
I ran into this problem today as well and it was because I moved my DocumentRoot from /var/www/html to /srv/www/html. As part of our security policies, we do not have the option to just Disable SELinux.
SO my fix, as I discovered was to change the SELinux file context for /srv to match /var. A compromise yes, but still better than disabling it altogether. Other than that... I made sure /srv/www and all subfolders had the httpd_sys_content_t to match the folders under /var/www and all is well now.
This is basically the same answer as David's, but just a little clearer, http serving directory has wrong SELinux security context set.
The full explanation to fix this is here, http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)
My issue was that I was housing my websites inside a different directory than the documentroot path of /var/www/, so I had to follow the 3rd option in the link above to correct. I set the same file context of my /websites/ directory to match that of the /var/www/. What was odd is earlier versions of CentOS 5.5 must not have had the SELinux installed/enabled, because my other servers had no issue with this and when running the ls -Z at the command prompt displayed those folders as 'unlabeled'.
I'm running CentOS 6.5 on AWS from the official marketplace minimal install. So when I ran the ls -Z command on my folders I saw exactly what the link above shows as a possible issue.
Running the chcon command fixed my issue!
Just replace html/ with the directory you want to use!
chcon -Rv --type=httpd_sys_content_t html/
chcon -Rv --user=system_u html/
On a side note I also had to disable iptables to get the routing working, the defaults were serving up blank pages.
service iptables stop
Hope that helps anyone with the same issue.
Envirnoment:
Linux - root file system on a SSD
DocumentRoot on a HDD and mounted via fstab
Restarting apache2 after boot - no problem
Seems to be a timing problem that apache is started before the fstab mounts are completed.
Workaround:
Define the DocumentRoot directory on the root file system with the correct owner, group and permissions. The directory may be empty.
Firstly, there is no reason at all to turn off selinux to fix this issue, just change the selinux file context.
Secondly, when changing selinux file context, you should to set up a permanent rule for that path, such that when new files are copied in and/or replace existing files, restorecon actually fixes the problem, instead of breaking it, as is the case when you only use chcon.
Thus, for a symlink'ed DocumentRoot (let's give the actual full path to the directory as '/media/myDoc' for this example), run these two commands:
semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"
restorecon -R /media/myDoc
Note, the full path is required when using semanage this way. You will not only fix the problem, but it won't break again when you run restorecon (or auto-relabel) in the future.
Something that I've noticed recently on two different machines is that Apache2 installed via MacPorts seems to have stopped launching when I boot up. The honest truth is that I can't swear it did so before, but it's something I think I'd notice because installing the LaunchDaemon is part of my install process. In fact, if I try to reload the LaunchDaemon, it fails:
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist
org.macports.apache2: Already loaded
Unless I start Apache manually (using sudo apachectl restart), grep'ing for either "apache2" or "httpd" in my process list only produces this:
$ sudo ps -ef | egrep "apache2|httpd"
0 52 1 0 0:00.06 ?? 0:00.08 /opt/local/bin/daemondo --label=apache2 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart ; --pid=none
1410639199 6960 6792 0 0:00.00 ttys001 0:00.00 egrep apache2|httpd
Looks like the daemon itself is in place, but no executable. As far as I know/can tell, the relevant executables (httpd and apachectl) are executable by everyone.
Has anyone else noticed this? Any ideas?
UPDATE
As requested below, I did execute launchctl list. The list is long and I'm not sure how to snip it, but suffice to say that no org.macports.* items are listed. That in itself is interesting because my MySQL daemon is loaded the same way. It works, but also doesn't appear in the list. Let me know if the entire output is really needed.
UPDATE
I assumed that I had executed launchctl list under sudo, but prompted by mipadi's comment below, I tried again ensuring that I did so and I assumed incorrectly. When executed under sudo, the MacPorts items appear:
51 - org.macports.mysql5
52 - org.macports.apache2
I'm not sure whether that will help, but it's a little more info nonetheless.
UPDATE
I've asked a different, but related, question at LaunchDaemons and Environment Variables. I'll update both questions as I learn more.
UPDATE
Today, based on mailing list input, I tried using a wildcard home directory. Academically, it's a little more inclusive than I'd like, but the practical reality is that I'm the only one using this computer; certainly the only one who'd have Apache config files laying around.
Include "/Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf"
Include "/Users/*/Library/Application Support/MacPorts/apache/conf.d/*.conf"
Unfortunately...
httpd: Syntax error on line 512 of /opt/local/apache2/conf/httpd.conf: Wildcard patterns not allowed in Include /Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf
I found my answer to this problem here:
https://trac.macports.org/ticket/36101
"I apparently fixed this when changing my local dnsmasq config. In /etc/hosts I added my servername (gala) to the loopback entry:
127.0.0.1 localhost gala
and then I changed ServerName in /opt/local/apache2/conf/httpd.conf to match:
ServerName gala
Apache now starts at boot for me."
Since I now know why Apache has stopped loading on startup, I'm going to articulate that answer and mark this question as answered. The reason Apache has stopped launching on boot is that I'm trying to share an httpd.conf file across systems. The config file needs to Include files from directories that exist within my home directory. Since the home directory is different on each machine, I was trying to reference the ${HOME} environment variable.
This works fine when manually starting after the machine is booted, but fails on startup because the environment variable isn't yet set. As mentioned above, see this question for more information.
Rob:
Had the same problem: "sudo launchctl load -w ..." started Apache2 while I was logged in, but did not work during startup (the "-w" should have taken care of that). Also, as you noticed, the daemon seems to be registered with launchctl. It will show up with "sudo launchctl list" and another "sudo launchctl load ..." will result in the error message.
I played with "sudo port load apache2" and "sudo port unload apache2", but could not get httpd running on reboot.
In the end, I got rid of the MacPorts startup item: "sudo port unload apache2", checked with "sudo launchctl list" that org.macports.apache2 is no longer registered for startup.
Afterwards, I followed the steps on http://diymacserver.com > Docs > Tiger > Starting Apache. I only had to adapt the path from /usr/local/... to /opt/local/...
Now the MacPorts Apache2 is starting fine with every reboot.
Good luck, Klaus
I found that my MacPorts apache2 was not starting on boot because of an “error” in my httpd.conf.
I was using
Listen 127.0.0.1:80
Listen 192.168.2.1:80
Listen 123.123.123.123:80 # Example IP, not the one I was really using
And in Console.app I was seeing
4/8/12 4:59:06.208 PM org.macports.apache2: (49)Can't assign requested address: make_sock: could not bind to address 192.168.2.1:80
4/8/12 4:59:06.208 PM org.macports.apache2: no listening sockets available, shutting down
4/8/12 4:59:06.208 PM org.macports.apache2: Unable to open logs
I tried adjusting permissions on all the log folders (despite the fact that logs were being written just fine when I manually started apache2) and that didn't help.
Even though the Apache Documentation for Listen clearly states
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.
I decided to try switching back to just using
Listen 80
And after doing so apache2 is starting on boot with no errors or warnings.
If you're using Subversion with Apache, you may find that Apache is not starting because the mod_dav_svn.so file has moved to /opt/local/libexec. You'll need to adjust your Apache startup files to account for the new location of this file.
In newer versions of MacPorts you can run sudo port load apache2 to instruct MacPorts to take care of the launchctl setup and automatically start the process. To stop the process run port unload.
After loading check /opt/local/apache2/logs/error_log for errors, including configuration issues.
In addition to my previous answer I have also found that sometimes Apache fails to start because something else with the system is not yet ready.
On one OS X Server machine I also use the DNS to create a “internal only” DNS name for the machine and that name is used in my Apache configuration. Sometimes when Apache tries to start the DNS server is not yet ready and Apache fails to load because the hostname isn’t valid.
I have also seen this on other non-Server systems without local DNS as well where something else required by Apache must not be ready yet.
One thing that has worked is to edit the apache2.wrapper located at /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper that MacPorts’ daemondo uses to start up Apache.
Edit the Start() function to add a sleep command to wait a bit before launching Apache.
Original (Lines 14-17 on my machine)
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && /opt/local/apache2/bin/apachectl start > /dev/null
}
With wait time added
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && sleep 10 && /opt/local/apache2/bin/apachectl start > /dev/null
}