When I try to recreate a file on smb server which was deleted from same client machine few moments ago, it gives error. What could be reason for that? No other client is accessing that file.
This problem is not always reproducible, however can be reproduced now and then.
Client is mac machine.
Check the smb.conf of the samba setup. It's possible to have delete access but not create access.
Related
I have Oracle Linux 8.5 in Oracle Cloud, and have been using the host for several months.
But today I was trying to setup vscode remote ssh and looks like I messed up the ssh key that I use to login to the host. Now I cannot!
I tried to follow this documentation and this thread to fix some commands.
However, that did not help! And in fact now the host having difficulty stopping quickly; rebooting looks fine.
Any ideas on how to correct this issue?! (Was having a lot of fun until this struck :) )
In the OCI console, go to the instance, and click on the "console connection", this will show you 2 options, one is create local connection, which will allow you to upload a new ssh key file. Or you can create a console connection and then update the authorized_keys file with your new id_rsa.pub contents
Console connection did NOT work for me. That's why I went by attaching the volume to another instance. The documentation I followed suggests to mount /dev/sdb3. However that did not work for me. Instead, I mounted /dev/ocivolume/root, and modified the ssh key there, and now works!
Have the machine list in the network. Changed a user, adding them to a group to give write permissions on a directory.
User still cannot make changes in directory, probably because the winows client is still logged in.
Is there a way to log the user out of the Samba connection without rebooting the machines? That seems a bit drastic.
The problem was the windows user could not write to the samba share.
A partial solution was to add that user to the group in question.
The other part of the solution was to add
writable = yes
to the smb.conf and restart samba, which immediately gave write access to the user.
The solution was not in the reboot.
I am sharing a directory on a ubuntu server over samba. When I mount the samba share with mac os x then it works perfectly fine. However, when I mount the samba share on windows and I enter the exact credentials as before, I get the error message:
\172.20.1.2\share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Multiple connections to a server or shared resource by the same user, using more than on user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
I have totally no idea what went wrong. When I enter the credentials on windows I even excluded the domain by entering the username as \admin . Does anyone know what the problem is or what I can check to get further details about what the actual problem is?
The problem that somehow the windows machine already "cached" an old credential. After restarting the machine it works fine.
I need to use nodejs to write file to a password protected shared folder on a remote machine running Windows server 2008 r2, how can I do impersonation things within nodejs like .net app does?
Thx in advance!!!
PS:
Sorry for the unclear description. The folder is set to shared across the internal network on the remote windows server system, the folder is set to "readonly" for the windows account explicitly created by the admin. The nodejs server is on the same internal network and need to access the remote shared folder, thus I think nodejs need to impersonate the windows account on the remote machine to read contents from the shared folder. My question is how to do the sorry for the unclear description. The folder is set to shared across the internal network on the remote windows server system, the folder is set to "readonly" for the windows account explicitly created by the admin. The nodejs server is on the same internal network and need to access the remote shared folder, thus I think nodejs need to impersonate the windows account on the remote machine to read contents from the shared folder. My question is how to do the impersonation stuff for nodejs?
Late to the party - but since there is no accepted answer...
You'll need to launch your node process using the account that has access to the network share. How this is done differs based on your setup. For example, if you're runnning node on a lLinux server trying to connect to the remote Windows server, then it's not going to be straightforward with node.
However; if you're running node on a Windows server, trying to connect to a remote share on another Windows server (which is what it sounds like your situation probably is). Again, you'll have to run your node script as a user with access to the remote share. If you need to do it from code, I'd suggest taking a look at my module node-windows. It doesn't provide remote share access specifically, but it will allow you to run command line code with a different account from within your node script.
I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.