My LGV30 phone running on Android 9 has a built-in screen recorder, but it displays an on-screen timer that can’t be removed. On newer models (LGV40, LGV50) running on Android 10/11 this timer can be toggled off. I know apps downloaded from the Google Playstore can’t record internal sound on Android 9. Before I download apk files from untrusted sources, I wanted to verify if installing the new version will still record internal audio or would it require root permission?
TLDR: When I copy a file from my macOS client to the FreeBSD NFS server, it’s written with 777 permission and owned by 501:staff.
In my example below, I want “license.properties” to be owned by myuser:staff and have 664 permissions.
This is the command I used to mount the NFS share on my Mac
mount -t nfs 192.168.1.229:/mnt/storage-mypc ~/test
mypc% pwd /mnt/storage-mypc/my-stuff mypc% ls -al total 140 drwsrwsr-x 10 myuser staff 11 Nov 22 23:44 apps mypc% ls -al apps total 66 -rwxrwxrwx 1 501 staff 232 Nov 10 15:06 license.properties mypc% cat /etc/exports /mnt/storage-mypc -maproot=myuser -network 192.168.1/24 /mnt/storage-mypc -maproot=myuser -network 192.168.2/24 mypc% showmount -e Exports list on localhost: /mnt/storage-mypc 192.168.1.0 192.168.2.0 mypc% cat /etc/rc.conf clear_tmp_enable="YES" syslogd_flags="-ss" sendmail_enable="NONE" hostname="mypc" wlans_iwm0="wlan0" ifconfig_wlan0="WPA DHCP" sshd_enable="YES" ntpd_enable="YES" powerd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="NO" zfs_enable="YES" ###################################### #mypc mountd_enable="YES" nfs_server_enable="YES" rpcbind_enable="YES" ifconfig_re0="inet 192.168.2.1 netmask 255.255.255.0"
‘quota’ specifies how much space may be used of a given tablespace. Space is allocated in extents – a logically contiguous series of blocks. When you create a table, you get one extent right off the bat. When you start inserting, you are using space that was previously allocated for the extent. Only when that extent is full and more space is needed will oracle attempt to allocate another extent, and only then will ‘quota’ come back into play.
Note: I think it was with 12c, perhaps with 11g, that the concept of ‘deferred’ allocation came into play. With that, a table is created with zero extents. At that point the table is really nothing but an entry in the data dictionary. The first (initial) extent is then not allocated at table creation, but when the first INSERT issued, thus requiring actual space allocated to the table.
Bottom line, your user is still able to insert rows because those rows are using space already acquired for the extent.
To pursue best practice for SQL Service accounts, I’m working through changing the SQL service account to be AD accounts for our existing SQL servers. The first one I did was fine because it was a fresh install. But for existing servers, making the change, I’m not sure about the “rights” required. The how-to states:
The SQL Server setup program will grant the necessary rights on the machine to that account during installation.
But if I’m not doing a fresh install, I guess I don’t know what the necessary rights are. I know I will:
- Apply Perform Volume Maintenance Tasks Right
- Apply Lock pages in memory right
- Disable interactive login for the AD service account
- Add AD service account to local Administrators group
Is there anything more needed to be done to successfully transfer the SQL Service account from NT SERVICEMSSQLSERVER?
In our environment, users were granted read/write/ddladmin permissions on tempdb database (dev/qa/prod).
These permissions will be lost when SQL Services restart, as tempdb rebuilds every time. One solution that is currently in place is – reapply the permissions scripts from a SQL Agent job, when ever SQLAgent starts. This is not accurate, as the users/permissions will be modified over time. Another thought, is take a daily backup (with a 15day retention policy) of tempdb permissions and use the same job to pick the latest file to reapply the permissions when SQL restarts. Is this an accurate solution for the problem.
I was trying to debug an application that was not working on specific environments and in my research I had multiple sources refer me to the tool Process Monitor found in live.sysinternals.comtools.
Not having admin access to my machine I made a request to IT to get permission to install and use this tool.
Fast forward a few days and I get a response saying that I would be able to use it under supervision and that “they are allowing it this time, but was definitely given a serious cautionary note with it.”
By this time I had already used another tool to read the “.bin” files in the library and I was able to find the error (the library had an updated bin file while the library required a previous version) and I no longer needed the tool.
I’m a little perplex at the response I got from IT. My question is how can the use of this tool be a concern to IT?
actually Davinci Resolve 16 runs fine on my Ubuntu system,except fairlight cannot access the microphone. maybe it has to do with permission rights? in the permission settings for the applications, there is no button to allow microphone access for Resolve. I tested it with other audio software that has the button. When i allow other apps to use the microphone, they record. How can i fix this? Or is it any other problem?
❯ adb sideload lineage-17.1-20201108-nightly-guacamole-signed.zip * daemon not running; starting now at tcp:5037 * daemon started successfully adb: sideload connection failed: insufficient permissions for device: user in plugdev group; are your udev rules wrong? See [http://developer.android.com/tools/device.html] for more information adb: trying pre-KitKat sideload method... adb: pre-KitKat sideload connection failed: insufficient permissions for device: user in plugdev group; are your udev rules wrong? See [http://developer.android.com/tools/device.html] for more information
Here is the question, image
Sticky bit is the correct answer, however definitions for sticky bit are:
When a directory’s sticky bit is set, the filesystem treats the files
in such directories in a special way so only the file’s owner, the
directory’s owner, or root user can rename or delete the file.
With directory owner being the main point here.
Since both users are part of the group “IT” which owns the “/projects” directory, why does sticky bit still work here? Peter is in fact unable to delete any files made by Stewie and vice versa despite both being part of a group that owns the directory. Is this a definition error or my misunderstanding?
Is it possible to have custom permissions within one document library? Say the document library has 4 folders:
- Human Resources
I have also created 4 corresponding user groups (HR, Finance, Services, Facilities)
I’d like the Human Resources folder BE VISIBLE only to the users in the Human Resources group, Finance – only to Finance users, etc). The folder structure above is simplified, there are actually more folders and some of them are subfolder,etc. Otherwise, I’d just create 4 document libraries each with different permissions.
I tried to right click on the Human Resource folder and chose ‘Manage Access’ I give a direct access only to the owners (myself) and the Human Resource group of users. It’s all good but when I try to access this folder as a HR user, I get the following notification. Is it possible to prevent it to appear each time an authorised user tries to access this folder. Or is it a wrong way of setting the permissions? Thanks