Everybody knows that Windows is not the best OS to work with. The other day I faced a problem, where I thought Windows is responsible for. We created a share on a MSSQL server and made it writeable for an AD user. I then mounted the share:
[root@myserver ~]# mount -t cifs //mssql_server/shared_folder /my/mountpoints/righthere -o username="peter.gunn",password="P45Sw0rD"
After doing some read/write tests I passed the new file location path to the developers. I was really surprised to hear that the application wasn’t able to write to that location. First of all I had a word with one of our Windows guys. He checked everything but couldn’t see a problem. I then tried to write to the share from different systems and it worked. A filelist of this folder showed something like this: -rwxr-xr-x root root testfile. That explains it . The application runs as a user and not as root. So I thought I could circumvent SAMBA/Windows in just executing:
[root@myserver ~]# chmod 777 /my/mountpoints/righthere. No success. After trying several different solutions like mounting a Linux share into that share location on the MSSQL server (A huge security risk, according to the Windows people) I finally fount the solution. After adding the userid of the user that runs the application to the options block of the mount command(-o username=”peter.gunn”, password=”P45Sw0rD, uid=1234), it worked like a charm. The owner of all files and folders in the share is the user with that userID now. To get the userID just execute the command.
[root@myserver ~]# id username